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

[Andrew W. Nosenko]

On Wed, Oct 17, 2012 at 12:45 AM, Eric Blake <address@hidden> wrote:
> On 10/16/2012 03:38 PM, Andrew W. Nosenko wrote:
>> Excuse, may be it's too late to party, but...  What is the reason to
>> to invent yet another macro name?  Anyway in the most packages there
>> will be one and the only one line:
>>     AC_CONFIG_MACRO_DIR([m4])
>> And even when the many dirs are need, they will be written one by one
>> in the theirs own macro call:
>>     AC_CONFIG_MACRO_DIR([m4])
>>     AC_CONFIG_MACRO_DIR([sub/m4])
>>     AC_CONFIG_MACRO_DIR([pack/m4])
>> (The reasons for such stacking is the same as the reasons for lineup
>> an arguments in a function call with a number of parameters in the
>> C-like languages -- aesthetics and ability to easy comment out some of
>> them.  The later becomes even more important in languages with the
>> only one style of comment -- from comment-char to the end-of-line,
>> like autoconf language.)
>
> 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?  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.
I think, noone uses automake without autoconf (the reverse is not
true), and noone uses libtool without automake (the reverse is not
true again).
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.

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?

>
> I haven't looked closely at these patches, so I still may end up
> tweaking the design a bit, but I appreciate Stefano stepping up to fill
> in a gap from my apparent lack of time at writing a patch that we first
> discussed that I should attempt more than a month ago.
>
>>
>> Therefore, a question raises: why to invent the new macro name?
>> Please note, I don't say about implementation.  I say about name.  If
>> someone whant to write (or generate, which is more probable) a number
>> of dirs in the one macro call -- no problems:
>>     AC_CONFIG_MACRO_DIR([m4], [sub/m4], [pack/m4])
>> or how it intended to be written, but in wast majority of cases I
>> expect the name in singular form to be more appropriate.  Just change
>> it's implementation, but left the name as is.  Allowing multiple dirs
>> where only one was allowed is backward compatible.
>> As a bonus: No needs in playing the game with "this macro is obsolete,
>> but we don't say you that evenn with -Wobsolete for backward
>> compatibility".
>
> I think we _can't_ mark the old macro obsolete, but at the same time, we
> must document that the old macro may appear _at most once_, and _prior
> to any use of the new macro_.
>
>> If te plural form (AC_CONFIG_MACRO_DIRS) is needed for some very heavy
>> reason, then it may me made just an alias to the AC_CONFIG_MACRO_DIR.
>
> Using just the m4 perspective, yes, the macros are aliases (they both do
> nothing).  But from the autoconf --trace perspective, having two macros
> matters, because not all tools used --trace (older libtool was using
> sed, rather poorly), and we don't want to break interoperability with
> old tools, all while still allowing new tools (automake 1.13) to take
> advantage of the multiple directories.
>
> --
> Eric Blake   address@hidden    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>



-- 
Andrew W. Nosenko <address@hidden>