Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well

From: Stefano Lattarini <[email-masked]>
Date: Thu, 15 Nov 2012 13:46:56 +0100

On 11/15/2012 01:00 PM, Eric Blake wrote:
> On 11/15/2012 03:58 AM, Stefano Lattarini wrote:
>>> As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing
>>> AC_CONFIG_MACRO_DIR.
>>>
>> The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS
>> with autoconf 2.69 as well.  It still doesn't work with autoconf 2.68
>> and earlier though, due to a bug in autom4te option parsing (fixed by
>> autoconf commit v2.68-120-gf4be358).  That could be fixed by using an
>> external file rather than stdin to pass aclocal the contents of
>> '$ac_config_macro_dirs_fallback'; but I rather do so in a separate
>> patch, with a dedicated rationale.
> 
> Yes, splitting that into a separate patch makes sense.
> 
> 
>> * aclocal.in ($ac_config_macro_dirs_fallback): New global variable,
>> contains m4 code to issue a fallback definition of AC_CONFIG_MACRO_DIRS
>> as an alias for the private macro _AM_CONFIG_MACRO_DIRS.
> 
> Tracing a new private macro - doesn't this imply that autoconf needs to
> add another macro to its list of preselections in order to pass the
> autoconf testsuite when using the new automake?  But don't let that stop
> this patch.
>
Well spotted.  But since I'm soon going to remove the private automake
macro '_AM_EXTRA_RECURSIVE_TARGETS' as well (the indirection it provides
is no longer needed now that aclocal automatically smashes extra
whitespace in the arguments of the traced macros), I'd rather wait and
make the autoconf update in a single batch.

>> +++ b/aclocal.in
>> @@ -45,6 +45,16 @@ use File::Path ();
>>
>>  # Some globals.
>>
>> +# Support AC_CONFIG_MACRO_DIRS also with older autoconf.
>> +# FIXME: To be removed in Automake 1.14, once we can assume autoconf
>> +#        2.70 or later.
>> +# NOTE: This variable deliberately contain no newlines.
>> +my $ac_config_macro_dirs_fallback =
>> +  "m4_ifndef([AC_CONFIG_MACRO_DIRS], [" .
>> +    "m4_defun([_AM_CONFIG_MACRO_DIRS], [])" .
>> +    "m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS(\$@)])" .
>> +  "])";
> 
> Hmm.  Packages that want to work with automake 1.12 and autoconf 2.69,
> but still use AC_CONFIG_MACRO_DIRS, may have also added a conditional
> definition of AC_CONFIG_MACRO_DIRS in their configure.ac.  But it turns
> out that you are injecting this snippet after m4sugar definitions (so
> m4_ifndef works) but before configure.ac, so your definition will take
> precedence.  Yep - that works :)
>
Good point (I must admit I hadn't even thought about this potential
issue, sigh).

>> +
>>  # We do not operate in threaded mode.
>>  $perl_threads = 0;
>>
>> @@ -716,16 +726,23 @@ sub trace_used_macros ()
>>    my %files = map { $map{$_} => 1 } keys %macro_seen;
>>    %files = strip_redundant_includes %files;
>>
>> -  my $traces = ($ENV{AUTOM4TE} || '@am_AUTOM4TE@');
>> -  $traces .= " --language Autoconf-without-aclocal-m4 ";
>> +  my $early_m4_code = "";
>>    # When AC_CONFIG_MACRO_DIRS is used, avoid possible spurious warnings
>>    # from autom4te about macros being "m4_require'd but not m4_defun'd";
>>    # for more background, see:
>>    # http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00004.html
>>    # as well as autoconf commit 'v2.69-44-g1ed0548', "warn: allow aclocal
>>    # to silence m4_require warnings".
>> -  $traces = "echo 'm4_define([m4_require_silent_probe], [-])' | " .
>> -            "$traces - ";
>> +  $early_m4_code .= "m4_define([m4_require_silent_probe], [-])";
>> +  # Support AC_CONFIG_MACRO_DIRS also with older autoconf.
>> +  # FIXME: To be removed in Automake 1.14, once we can assume autoconf
>> +  #        2.70 or later.
>> +  $early_m4_code .= $ac_config_macro_dirs_fallback;
> 
> If you are adding a fallback for AC_CONFIG_MACRO_DIRS when running
> aclocal, you'll also need to add that fallback when running automake.
> (But reading further, it looks like you did.)
> 
>> @@ -738,11 +755,12 @@ sub trace_used_macros ()
>>  		     'AC_DEFUN_ONCE',
>>  		     'AU_DEFUN',
>>  		     '_AM_AUTOCONF_VERSION',
>> -		     # FIXME: We still need to trace AC_CONFIG_MACRO_DIR
>> -                     # for compatibility with older autoconf.  Remove this
>> -                     # when we can assume Autoconf 2.70 or later.
>> +		     'AC_CONFIG_MACRO_DIR_TRACE',
>> +                     # FIXME: This is an hack for compatibility with older
> 
> s/an hack/a hack/ - use 'a' before a pronounced 'h', 'an' before a
> silent 'h'.
>
As you have already told me several times already.  Sorry for forgetting
once again.

>> +                     # autoconf.  Remove this in Automake 1.14, when we can
>> +                     # assume Autoconf 2.70 or later.
>>  		     'AC_CONFIG_MACRO_DIR',
>> -		     'AC_CONFIG_MACRO_DIR_TRACE')),
>> +		     '_AM_CONFIG_MACRO_DIRS')),
> 
> Isn't it really: "These next two variables are a hack"
>
Yes.  Isn't that clear?   Anyway, to remove possible confusion, I've
updated the comment to use your wording.

>> --- a/doc/automake.texi
>> +++ b/doc/automake.texi
>>
>>  @example
>> -AC_CONFIG_MACRO_DIR([m4])
>> +AC_CONFIG_MACRO_DIRS([m4])
>>  @end example
> 
> It _might_ be worth mentioning that you must use one or both of automake
> 1.13 or autoconf 2.70 to have this work,
>
Actually, Automake 1.13 is both enough *and* required to have this work
(after the next patch, that you have already reviewed); and since this
will be the manual for 1.13, there is no need to specify that explicitly.

> and that back-compat to automake 1.12 and autoconf 2.69 requires manual
> effort in configure.ac.
>
> Meanwhile, I ought to do the same in the autoconf manual.
> 
> ACK once you fix the comment.
> 
Done:

   ...
   'AC_CONFIG_MACRO_DIR_TRACE',
   # FIXME: Tracing the next two macros is a hack for
   # compatibility with older autoconf.  Remove this in
   # Automake 1.14, when we can assume Autoconf 2.70 or
   # later.
   'AC_CONFIG_MACRO_DIR',
   '_AM_CONFIG_MACRO_DIRS')),
   ...

Thanks,
  Stefano