bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))


From: Gary V. Vaughan
Subject: Re: bug#19370: Acknowledgement (LT 2.4.4 regression (vs. 2.4.2))
Date: Fri, 16 Jan 2015 18:49:12 +0000

[[Adding Autoconf List, the home of autoreconf]]

On Jan 16, 2015, at 1:26 PM, Gary V. Vaughan <address@hidden> wrote:
>>> And the problem is that autoreconf, as called from the
>>> autogen.sh in the tarball, still runs the tools in the wrong order.
>>> Autoreconf stupidly runs aclocal first, and then calls libtoolize which
>>> adds more m4 files to AC_CONFIG_MACRO_DIR, and that in turn causes
>>> aclocal.m4 to be out of date (because it needs to be regenerated to pick
>>> up the local versions of the libtoolize added m4 files added to
>>> ../config/ after it was first generated).
>> 
>> actually, (at least modern enough) autoreconf runs the aclocal twice.
>> Once before libtoolize call (do detect whether it should call the
>> libtoolize tool at all) and second time [1] after libtoolize to
>> incorporate the macros.
> 
> That's good to know.  I stopped closely following autoconf development a
> few years ago, and didn't realise this was finally cleaned up.  Some of
> these corner case may be because of my slightly out of date view of how
> these tools interact :-(

Now that I think about it, why is it necessary to run aclocal just to
find out whether LT_INIT, AM_PROG_LIBTOOL or AC_PROG_LIBTOOL is invoked?
I know that for a full m4 --trace run, one needs to have some (possibly
outdated) versions of required macros available, but it's very easy to
work around that: see the implementation of `func_require_libtoolize` in
the libtool bootstrap script (my clean rewrite of the gnulib bootstrap
script).

Further, now that autoconf is actively maintained again, why do we have
a vestigial autoreconf and a whole zoo of autogen.sh and bootstrap scripts?
Wouldn't it make more sense to centralize and maintain all of this in the
one true autoreconf?  Merging my bootstrap script with the latest autoreconf
eliminates the spurious rerun of aclocal, and brings support for gettext,
gnulib and per-project customizations.

It doesn't seem like a great deal of work to translate 700 lines of perl
into shell, fold it into bootstrap, and ship the result as autoreconf in the
next release of Autoconf.  Then everyone can go back to running `autoreconf
-fvi` and be done with the whole mess of wrapper scripts...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]