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

[Andrew W. Nosenko]

The answer is two fold.  Lyrics and pragmatics.
Pragmatic part is very simple: If you feel from your experience that
the path with introducing the new macro is better -- then let it be.
After all, you know about this triplet (autconf+automake+libtool) far
more than me.

Lyrics is below, feel free to skip it.

On Wed, Oct 17, 2012 at 1:14 AM, Eric Blake <address@hidden> wrote:
> 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?

There were no pain for me personally.  I was aware about change
because it was announced.  Sure, anyone on the distro-building side
was aware also (unable to believe that maintainer of the some package
isn't subscribed to the corresponding developer's mailing list(s)).
As for the regular distro-users, they are just don't play the games
with "upgrade this package and downgrade that package".  They just,
usually, accept all upgrades pushed from vendor.

You may argue that jump from version to version is a risk that may be
unacceptable or just too time and resource consuming.  Yes.  But if
allowed risk or resources are zero, then autoconf won't be upgraded
also.  Just because it's also risk.  If some amount of risk is
acceptable, then it may be limited at the very low level with some
love and care from the libtool side: branch from the 2.4.2 point,
apply one and only one patch, which brings compatibility with the new
AC_CONFIG_MACRO_DIR, and release 2.4.4.  If need, repeat for
2.2.10->2.2.12, ...

Of course, it's all true only if required changes at the libtool side
can be localized (in the sense of touched pieces of code).  If
changes, which required for that, are spread across the whole libtool,
or too complex for be reasonable sure in absence of unwanted
side-effects -- then yes, my proposal is out of luck.

>
>> 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.

Yes, but this goal is missed.  And missed very far and heavy.  At the
current state, libtool is just a semi-portable automake plugin for
generation of shared libraries.  May be I'm not too polite, but can
you, or anyone else, point me to the even one real live non-died
project, which uses libtool without automake?  (Before you ask: Yes,
of course, Feel free to forward this message to libtool mailing list)

>
>> 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.

See "Pragmatic part" above :-)
For me it's enough that idea to allow multiple dirs without
introducing the new macro name was considered.

>> 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.

Yes, but could don't know, or provide some "plugin" interface for
libtool or libtool-like projects, or just have libtool as it's
optional extension as part of package.  May be I, personally, would to
prefer the latter.

-- 
Andrew W. Nosenko <address@hidden>