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

[Stefano Lattarini]

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).
> 
> 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,
>
Hmm...  Now that I think about it, this would cause aclocal to add such a
directory twice to its search path (once because it's traced as an argument
to AC_CONFIG_MACRO_DIRS, and once because it's traced as an argument to the
auxiliary call to AC_CONFIG_MACRO_DIR you are proposing); not a big deal,
but annoying.  Instead, why not fix the development version of libtool to
also support AC_CONFIG_MACRO_DIRS?  There would be no regression, since
such the libtoolize with tracing capabilities has never be released.

> but if you are porting to older libtool, explicitly spelling out the old
> name is important.
> 

Regards,
  Stefano