GNU bug report logs - #8168
macros directory not created automatically

Previous Next

Full log

View this message in rfc822 format

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 8168 <at> debbugs.gnu.org, Javier Jardón <jjardon <at> gnome.org>, automake-patches <at> gnu.org
Subject: bug#8168: macros directory not created automatically
Date: Fri, 1 Apr 2011 15:26:47 +0200

* Stefano Lattarini wrote on Fri, Apr 01, 2011 at 03:13:19PM CEST:
> On Friday 01 April 2011, Ralf Wildenhues wrote:
> > Patch 2:
> > - Should `--install -I foo/bar/m4' create intermediate directories, or
> >   would we suspect a typo?
> >
> I'd say the latter.  It should be good enough for the all legitimate uses,
> and will make the implementation slightly simpler (we can use the builtin
> function `mkdir' instead of the `mkpath' function from module File::Path).
> Also, in case the users start complaining about this limitation, we can
> still easily lift it, without breaking backward-compatibility.

OK.

> > - Should `--install -I $dir' also create an absolute $dir?
> >
> I think so.  Why shouldn't it?

Well, I don't understand what a legitimate use case would be, that's
why.  You need a relative path anyway for --install to copy files there.
aclocal won't install to an absolute first -I directory, because that
is usually not what was intended (it typically comes from having to work
around the non-existence of ACLOCAL_PATH by specifying ACLOCAL='aclocal
-I /some/system/dir').

Do you see know what it may not be a good idea to try to create such a
directory?

> > (I think "no" with both questions, but it would be good to be sure.)
> >
> The answer to both question is in truth "yes".  Good you asked :-)


> > Patch 1:
> > - Should the warning/erroring bits differentiate between relative or
> >   absolute directory names?  I'm considering to not warn at all about
> >   absolute names, as we might not have any control over the tree there.
> >
> I agree about not having a warning. But a message with `verb' (thus
> displayed only when the user requests verbose output) would be useful
> also in this case, no?

Sure.

> > - For a relative directory, a warning seems appropriate; and verb is
> >   not the right function for that.
> >
> Well, in truth, I didn't intend for that message to be a warning -- it's
> just a verbose mesage that can help in debugging.  I think `verb' is
> appropriate for such an usage.  Probably I should fix the ChangeLog
> entry to be more consistent with the intended behaviour; i.e., from
> 
>     * aclocal.in (scan_m4_dirs): If a user-specified "include
>     directory" is unreadable or non-existent, do not issue a
>     fatal error anymore, but simply issue a warning, and only
>     when running in verbose mode.
> 
> to:
> 
>     * aclocal.in (scan_m4_dirs): If a user-specified "include
>     directory" is unreadable or non-existent, do not issue a
>     fatal error anymore, but only give a proper message when
>     running in verbose mode.
> 
> Would that be better?

But why would a warning be inappropriate?  It can be turned off, and it
can signal a command-line typo.  Very few users use --verbose, and those
that do, do not run it in order to get notified of typos.

We don't have to work identical to a preprocessor here.  Unlike a
preprocessor, aclocal is much more at the whim of bogus (or missing)
macro files, because we scan all files in a directory, not just
explicitly included ones, so some control over the search path is a
good thing in general.

> >   The most fitting category would be
> >   syntax, barring anything better?  (And yes, that means aclocal -Werror
> >   would then error out, but that could be considered a good thing).
> >   But it seems 'verb' would be appropriate for absolute directories.
> > 
> > What do you think?
> >
> I think that we should behave similarly to how gcc, m4 and perl (and
> probably many other programs) behave -- i.e., no warning on `-I' used
> with non-existent directories, either relative or absolute:
>   $ gcc -I /none foo.c
>   $ m4 -I /none </dev/null
>   $ perl -I /none -e '1;'

See above.

> > > +	  xsystem ('mkdir', $destdir)
> > > +            unless -d $destdir;
> > 
> > Perl has a mkdir function, there is no need for xsystem.
> >
> Agreed (and testcases updated accordingly).

Be sure to check for errors.

Thanks,
Ralf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.