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

Previous Next

Full log

View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
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:55:44 +0200

On Friday 01 April 2011, Ralf Wildenhues wrote:
> * 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 $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
>
Ahhh, now your position makes perfect sense, and I agree with it.
I'll fix the patch and the testuite shortly(ish).

BTW, I dimly remembered some non-obvious interaction between `--install'
and absolute dirnames, and I had looked at the documentation searching
for it before answering your previous, but nothing came up.  Now I see
that the behaviour is indeed documented, but not in a completely
"appropriate" place (it's only in the introduction to aclocal, not in
the documentation of the `--install' option).  Maybe this could be
improved.

> (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?
>
Yes, and I agree with you now.

> > > Patch 1:
> > > - 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,
>
Only turning off other warnings too ...

> 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.
>
Maybe a new warning category could be introduced?

> 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.
>
OK, you have a point here.

> > >   The most fitting category would be syntax, barring anything
> > >   better?
>
But we would need something better IMHO.

> > >   (And yes, that means aclocal -Werror
> > >   would then error out, but that could be considered a good thing).
>
Yes, but only if the warning categories have a sufficient granularity.

> > >   But it seems 'verb' would be appropriate for absolute directories.

 
> > > > +	  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.
>
I did (and the testsuite would have caught a missing check anyway ;-)


Regards,
   Stefano

Previous Next

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