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