[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks
Date: Tue, 13 Nov 2012 15:55:53 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2

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 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:
>   -
>   -
>> 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 specifies, and belongs to a file
( 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
> 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 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]