Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks

[Eric Blake]

On 11/13/2012 03:11 PM, Nick Bowler wrote:
>> If AC_CONFIG_MACRO_DIR_TRACE has a trace hit, then autoconf 2.70 is in
>> effect.  Either the configure.ac used AC_CONFIG_MACRO_DIR (old-style)
>> (and you can assume ACLOCAL_AMFLAGS will exist and match), or it used
>> AC_CONFIG_MACRO_DIRS (new-style) (and ACLOACL_AMFLAGS is no longer
>> required),
> 
> No, these are not the only possibilities if AC_CONFIG_MACRO_DIR_TRACE
> appears in the m4 traces.  You have forgotten the case where ACLOCAL_AMFLAGS
> contains more than one -I option, and a user used AC_CONFIG_MACRO_DIR to
> shut up libtool.  This case was labeled (2) in both of the following:
> 
>   - https://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00057.html
>   - https://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00075.html
> 
>> but either way, this is the canonical location to be used.

If the user has AC_CONFIG_MACRO_DIR_TRACE out of sync with
ACLOCAL_AMFLAGS, then aclocal (via automake) should use the union of
both specifications for the list of secondary directories, as well as
warn the user how to get things back in sync.  I don't see how this
breaks anything, but the burden is on automake, not autoconf, to check
that they are in sync when both are present.

> 
> No, because in the "shut up libtool" case there is an additional
> directory to consider that will not be found in the m4 traces.

Yes, but that directory appears via ACLOCAL_AMFLAGS, which is outside
the realm of what configure.ac specifies, and belongs to a file
(Makefile.am) that is processed owned by aclocal.  So it is up to
automake, not autoconf, to ensure that this case works.

> 
>> Automake 1.13 will error out if ACLOCAL_AMFLAGS exists but does not
>> match the trace (thus enforcing that _if_ you use the redundancy, you
>> use it correctly); but will not care if you omit ACLOCAL_AMFLAGS.
> 
> Then this will represent a regression in Automake in the case where a
> configure.ac does not include AC_CONFIG_MACRO_DIR all (for example,
> this would regress for at least GNU Gettext and my own packages).

Only if you use -Werror to turn that warning into a hard error.
Otherwise, it is a warning, but no change in behavior.  If you choose to
silence the warnings, you would update your configure.ac to add the
necessary AC_CONFIG_MACRO_DIR[S] lines (possibly with my
m4_default_define hack to ensure that you are not forcing everyone
bootstrapping your package to use newer autotools).

>  But I
> believe you may be mistaken: I personally tested the patch series that
> Stefano posted and did not observe the behaviour you describe.  So this
> will only be the case if Automake's behaviour has changed in the
> interim...

There may still be a patch needed to automake to properly honor the
union of directories learned by trace and the directories specified by
ACLOCAL_AMFLAGS, when the latter is present.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature