bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks

[Eric Blake]

On 11/14/2012 07:41 AM, Stefano Lattarini wrote:
>> If I understand your argument correctly, you are claiming that
>> AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE,
>> so that case (2) can be distinguished by automake; but that would mean
>> that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and
>> AC_CONFIG_MACRO_DIR for case (0) to work.
>>
> Currently, Automake is already tracing both AC_CONFIG_MACRO_DIR and
> AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages.  Are
> you arguing that tracing both macros is a bad idea?  If yes, I might
> add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and
> AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detected, so that
> packages using older autoconf but newer aclocal/automake will still be
> able to rely on that macros.  And this hack will be removed in Automake
> 1.14 (when we'll start requiring autoconf 2.70), so this clumsy extra
> code won't pollute our codebase for too long.
> 
> Opinions?

As long as you aim to interoperate with autoconf 2.69 but still diagnose
mismatches between ACLOCAL_AMFLAGS on the primary directory [granted,
the mistmatch diagnosis patch still needs to be written], then you have
to trace AC_CONFIG_MACRO_DIR.  However, you should only need to pay
attention to the AC_CONFIG_MACRO_DIR trace in the case where
AC_CONFIG_MACRO_DIR_TRACE had no hits (that is, only for older
autoconf).  On the other hand, it is harmless if, under newer autoconf,
you pay attention to both macros - it just means that you will encounter
the primary directory twice (once under each trace).

As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing
AC_CONFIG_MACRO_DIR.

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

signature.asc
Description: OpenPGP digital signature