Re: [PATCH 1/6] aclocal: multiple local m4 macro dirs with AC_CONFIG_MACRO_DIRS

[Stefano Lattarini]

Hi Eric, thanks for the feedback.

On 11/09/2012 09:31 PM, Eric Blake wrote:
> On 11/03/2012 06:36 AM, Stefano Lattarini wrote:
>> A new macro 'AC_CONFIG_MACRO_DIRS' has been recently introduced in
>> autoconf (and is expected to appear in the autoconf 2.70 release),
>> allowing us to declare several local m4 macro directories for a
>> package.
>>
> 
>> @@ -731,7 +731,8 @@ sub trace_used_macros ()
>>                   'AC_DEFUN_ONCE',
>>                   'AU_DEFUN',
>>                   '_AM_AUTOCONF_VERSION',
>> -                 'AC_CONFIG_MACRO_DIR')),
>> +                 'AC_CONFIG_MACRO_DIR',
>> +                 'AC_CONFIG_MACRO_DIRS')),
> 
> Here, you should just trace AC_CONFIG_MACRO_DIR_TRACE, once I finish
> posting my autoconf patches.
>
I will (I'll do a full re-roll of this series once your Autoconf series
is ready).

>> @@ -763,7 +764,11 @@ sub trace_used_macros ()
>>          }
>>        elsif ($macro eq 'AC_CONFIG_MACRO_DIR')
>>          {
>> -          $ac_config_macro_dir = $arg1;
>> +          @ac_config_macro_dirs = ($arg1);
>> +        }
>> +      elsif ($macro eq 'AC_CONFIG_MACRO_DIRS')
>> +        {
>> +          push @ac_config_macro_dirs, split (/\s+/, $arg1);
> 
> You still have to trace AC_CONFIG_MACRO_DIR for the sake of older
> autoconf;
>
No, I'd rather just trace AC_CONFIG_MACRO_DIR_TRACE.  This is the
rationale:

 1. If someone uses autoconf <= 2.69, he'll have to use ACLOCAL_AMFLAGS
    anyway; doing so will be OK with Automake 1.13.x as well, since we
    don't yet warn about that obsolescent variable (and won't until
    Automake 1.14).

 2. In Automake 1.14, I'll just bump the Autoconf requirement to from
    2.65 to 2.70 anyway (since I want to start taking advantage of POSIX
    shell features in the Automake-generated recipes), so the issue of
    compatibility with older autoconf will be moot.

> but if AC_CONFIG_MACRO_DIR_TRACE exists, you will end up
> seeing the first directory under both macros.  So this logic will need
> to check if the new macro exists, and if so, ignore the old macro (or
> else continue to trace both, but do duplicate elision at the end; and
> duplicate elision might make sense anyways).  Also, since
> AC_CONFIG_MACRO_DIR_TRACE is called once per directory (no matter how
> many directories were crammed in one AC_CONFIG_MACRO_DIRS call), you
> don't need to do any of the split(/\s+/) magic.
>
Delegating away work -- I like that ;-)

Thanks,
  Stefano