On 11/12/2012 08:42 AM, Nick Bowler wrote: > On 2012-11-09 15:53 -0700, Eric Blake wrote: >> Too many legacy tools exist for us to unilaterally quit supporting >> AC_CONFIG_MACRO_DIR - it is feasible for someone to want their >> package to bootstrap with both automake 1.13 and libtool 2.4.2, >> where the newer automake will only trace the new style of multiple >> directory listings, but the older libtool does a sed and settles >> on the one use of the old name. So, we let both macros forward >> to a new tracing macro, which also has the benefit of sanitizing >> calls into one directory per trace; we also ensure that the old >> macro is always traced, and appears at most once and before any >> use of the new macro. > > If the goal is compatibility with existing behaviour of libtool, > then we must allow multiple invocations of AC_CONFIG_MACRO_DIR and > they must emit AC_CONFIG_MACRO_DIR_TRACE in the reverse order.
No, existing use of libtool was intended to honor only the first AC_CONFIG_MACRO_DIR, but due to a bug, actually honored only the last. It does NOT honor multiple directories, so anyone actually _using_ AC_CONFIG_MACRO_DIR with existing libtool could only successfully use it once. The new code in autoconf enforces that usage, since anything else is confusing. > >>From the look of things, this patch intentionally breaks such > invocations, which currently work (since AC_CONFIG_MACRO_DIR > doesn't do anything). Yes, it DOES do something - it tells libtool where to install files, and libtool needs to install files in the FIRST directory, not the last. So this change is indeed intentional. > > I still maintain that we should not touch this macro at all. We haven't done anything to this macro except for hardening it up to detect invalid usage. > No > released version of libtool requires AC_CONFIG_MACRO_DIR to be used > in configure.ac. Yes it does - libtoolize warns noisily if you didn't use AC_CONFIG_MACRO_DIR in configure.ac, so people have been adding it because of libtool's warnings. > Any package targeting compatibility with as-yet- > unreleased versions of automake (read: such packages are by definition > new developments) and old versions of libtool can simply elide the > macro from their configure.ac, and things will work. Yes, they will work (because the message from libtool was a warning, not an error), but silence is better than warnings. Hence my goal of allowing the macro to continue to be used in a manner which will shut up older libtoolize warnings. -- Eric Blake [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
