* 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
