On 07/04/2012 04:55 AM, Stefano Lattarini wrote: > This will allow projects to use several m4 macro local dirs. This is > especially important for projects that are used as nested subpackages > of larger projects. > > See also: > <http://lists.gnu.org/archive/html/autoconf/2011-12/msg00037.html> > <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00010.html> > > * doc/autoconf.texi (@node "Input" @defmac "AC_CONFIG_MACRO_DIR"): > Update signature of and comments about AC_CONFIG_MACRO_DIR. > * lib/autoconf/general.m4 (AC_CONFIG_MACRO_DIR): Likewise. No need to > do other changes because this macro expands to empty anyway, and only > exists to be traced by other tools like aclocal and autoreconf.
I'm generally in favor of the idea, however, I'm not sure if we are going far enough, or if we will be causing interaction problems with existing clients. Would it also make sense to allow multiple calls to AC_CONFIG_MACRO_DIR to stack, as in: AC_CONFIG_MACRO_DIR([dir1]) AC_CONFIG_MACRO_DIR([dir2]) And should we mention that the first directory listed has special significance to other tools like libtool that use the first directory (and ignore subsequent directories) when first preparing a package with libtoolize? For that matter, I'd have to investigate whether libtoolize uses grep or autoconf tracing; if the former, then we have to insist on stacked usage rather than a whitespace-separated list, to minimize confusion when using older libtool that doesn't understand this documented newer semantic of autoconf. (Obviously, if libtool uses grep, we should fix that as well...) -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
