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

From: Eric Blake <[email-masked]>
Date: Thu, 15 Nov 2012 05:00:35 -0700

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.

> +++ 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 :)

> +
>  # 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'.

> +                     # 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"

> +++ b/doc/automake.texi
> @@ -3605,10 +3605,10 @@ will be almost impossible to share macros between packages.
>  The second possibility, which we do recommend, is to write each macro
>  in its own file and gather all these files in a directory.  This
>  directory is usually called @file{m4/}.  Then it's enough to update
> -@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_DIR}:
> +@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_DIRS}:
> 
>  @example
> -AC_CONFIG_MACRO_DIR([m4])
> +AC_CONFIG_MACRO_DIRS([m4])
>  @end example
> 
>  @command{aclocal} will then take care of automatically adding @file{m4/}
> @@ -3731,7 +3731,7 @@ MyPackage uses an @file{m4/} directory to store local macros as
>  explained in @ref{Local Macros}, and has
> 
>  @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, 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.

-- 
Eric Blake   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org