Re: installable gnulib library

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 02:45:57PM CEST:
> On 9 Oct 2010, at 15:13, Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 05:48:04AM CEST:
> >> ...ah, that's because autoreconf is still running aclocal before 
> >> libtoolize,

> > autoreconf runs aclocal to find out by tracing whether AC_PROG_LIBTOOL
> > is used, then runs libtoolize if needed, then runs aclocal again if
> > needed.  I think that is just about the right way to do it, barring
> > extra warnings.
> 
> I stand corrected.  In this case, however, there was no second aclocal
> run, although I suppose technically it was not required.

autoreconf reruns aclocal if --install was passed.  It might be silent
even with --verbose though.

> Is it not the case that autoreconf of a package to replace buggy macro
> files that the first aclocal could fail catastrophically?

Yes, I suppose that can happen.

> And if that happens, can autoconf recover?

Dunno.  Wanna write a test case for the Autoconf testsuite?

> > I haven't looked at your recently posted tracing script for whether that
> > does this much differently, but I'm guessing not.
> 
> Actually yes, very differently.  And IMHO much more robustly than either
> a spurious aclocal run with potentially old/missing/broken macros in
> place, AND more robustly that running sed.  The new method I'm advocating
> uses m4 with a specially tuned mini-acgeneral.m4 and with include macros
> disabled to avoid exactly the problems I just described to provide accurate
> trace results to determine which bootstrap tools need to be run - and in
> the correct order.
> 
> In that thread, I suggested that Autoconf would benefit from adopting
> this method with the caveat that the mini-acgeneral.m4 would need to be
> maintained and tuned to allow tracing of interesting macros required to
> bootstrap robustly.
> 
> With my rewrite of the gnulib bootstrap script, also posted recently due
> to lack of time to finish all the testing I would have liked anytime
> some, autoreconf *is* called under normal circumstances, but by default
> it first uses my new trace method to discover which pre-aclocal tools
> should be run first... and then effectively turns off autopoint and
> libtoolize by exporting AUTOPOINT=true and LIBTOOLIZE=true in autoreconf's
> environment.  Of course all that can be overridden in bootstrap.conf as
> preferred by any project that adopts the bootstrap script.

Sounds like good ideas.  Of course, it also sounds like things would
even better be fixed higher upstream, namely in autoreconf.  If you can
demonstrate your tracing tool to be more robust, or with less spurious
warnings, all the better.  Please if at all possible add test coverage
for the bugs fixed, so we don't regress later.

Thanks,
Ralf