Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal

[Eric Blake]

On 10/16/2012 04:08 PM, Andrew W. Nosenko wrote:
>> The problem is that existing tools (here's looking at you libtool) are
>> inconsistent if you HAPPEN to use AC_CONFIG_MACRO_DIR - some use the
>> first directory, others use the last, and some crash altogether.
>> Back-compat requires that we have a new macro, so that new tools that
>> agree on a common sane semantics use the new name, and where the new
>> name calls AC_CONFIG_MACRO_DIR() exactly once, on the first directory,
>> if AC_CONFIG_MACRO_DIR had not already been used, for best
>> interoperability with old tools.
> 
> May be then the libtool should be fixed?

Yes, libtool will eventually be fixed.  But we cannot assume that people
will do a lock-step upgrade of both tools, so it is in our best interest
to avoid forcing an upgrade of libtool just to use new autoconf.

>  I remember how zlib and
> libxml2 were change synchronously (zlib was changed for fix a bug and
> libxml2 for be on-par with changed interface).  And these packages are
> far less coupled than autoconf+automake+libtool.

And do you also remember the pain if you upgraded one but not the other?

> I think, noone uses automake without autoconf (the reverse is not
> true),

Correct (automake REQUIRES autoconf).

> and noone uses libtool without automake (the reverse is not
> true again).

Wrong.  For better or worse, Libtool has a goal of specifically being
usable even without autoconf or automake.

> Therefore, I think that noone outside of autotools developers
> community will be heavy shocked by simultaneous release of libtool-2.6
> (or 2.4.3) and automake-1.13 + requirement that only libtool-2.6 (or
> 2.4.3) is compatible with automake-2.13.

Sorry, but I'm not willing to require a lock-step upgrade of both tools
if it can be easily avoided.  There really IS benefit to back-compat
paths where you can upgrade one tool and not the other, even if it is
slightly more work for autoconf to guarantee that it will happen smoothly.

> 
> Or it is indeed so hard to fix libtool's search order and strategy
> that build workarounds on the automake side (the side that does not
> depend on libtool and even may know nothing about libtool's existence)
> is easier than fix the real problem on the right side?

Actually, automake DOES know about libtool's existence, and makes
decisions on what to stick in Makefile.in based on whether libtool is in
use.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature