Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument

[Stefano Lattarini]

Reference:
<http://lists.gnu.org/archive/html/autoconf-patches/2012-07/msg00000.html>

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?

Regards,
  Stefano