Reference:
<http://lists.gnu.org/archive/html/autoconf-patches/2012-07/msg00000.html>
On 08/21/2012 11:37 AM, Stefano Lattarini wrote:
>
> On 07/04/2012 01:51 PM, Stefano Lattarini wrote:
>> On 07/04/2012 01:28 PM, Eric Blake wrote:
>>> On 07/04/2012 05:03 AM, Eric Blake wrote:
>>>
>>>> Would it also make sense to allow multiple calls to AC_CONFIG_MACRO_DIR
>>>> to stack, as in:
>>>>
>>>> AC_CONFIG_MACRO_DIR([dir1])
>>>> AC_CONFIG_MACRO_DIR([dir2])
>>>>
>>>> And should we mention that the first directory listed has special
>>>> significance to other tools like libtool that use the first directory
>>>> (and ignore subsequent directories) when first preparing a package with
>>>> libtoolize? For that matter, I'd have to investigate whether libtoolize
>>>> uses grep or autoconf tracing;
>>>
>>> Libtool 2.4.2 (the current release) uses grep tracing; but libtool
>>> commit 2a71b02b has already converted over to m4 tracing. I'm not sure
>>> if the m4 tracing will gracefully handle whitespace-separated
>>> directories or multiple invocations, but the old code:
>>>
>>> - /AC_CONFIG_MACRO_DIR(/ {
>>> - s,^.*AC_CONFIG_MACRO_DIR([[ ]*\([^])]*\).*$,ac_macro_dir=\1,
>>> - p
>>> - }
>>>
>>> definitely does NOT handle whitespace lists, and with multiple calls,
>>> appears to reassign $ac_macro_dir to the last call rather than the first
>>> (yuck).
>>>
>> Thanks for digging this out (and sorry for duplicating part of it in my
>> earlier reply).
>>
>>> I think we're stuck for compatibility with providing a new macro for
>>> listing subsidiary directories, and that users that plan to interact
>>> with old libtool must use something like:
>>>
>>> AC_CONFIG_MACRO_DIR([dir1])
>>> AC_CONFIG_MACRO_DIRS([dir2 dir3])
>>> AC_CONFIG_MACRO_DIRS([dir4])
>>>
>>> where the new macro can stack or take whitespace lists. The new macro
>>> can also auto-call AC_CONFIG_MACRO_DIR() for its first argument for new
>>> libtool that traces rather than using sed, but if you are porting to
>>> older libtool, explicitly spelling out the old name is important.
>>>
>> OK. The new code to support this in aclocal will amount to one line of
>> code :-) And the 'AC_CONFIG_MACRO_DIRS' name is preferable IMHO, being
>> more faithful to the intended semantics (several directories supported).
>>
>> Anyway, to avoid a continuous accretion of backward-compatibility cruft, I
>> think we should also "deprecate" AC_CONFIG_MACRO_DIR in the documentation,
>> stating that it should only be required by older libtools, and add a FIXME
>> comment to its definition in general.m4 telling that it should be removed
>> by 2014 or so.
>>
> Ping on this?
>
Another ping. Automake 1.13 will need to know the interface of this
new Autoconf feature in order to integrate with it correctly, and start
deprecating ACLOCAL_AMFLAGS (in documentation only until Autoconf 2.70
is out; after that, also with warnings in the 'obsolete' category).
Regards,
Stefano
