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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
