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
