On 07/04/2012 01:03 PM, Eric Blake wrote: > 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]) > I agree that this stacked usage is definitely worth supporting. And is probably easier to document, as well as safer in the face of inferior tools still grepping of configure.ac instead of using proper tracing.
So I'll adjust my documentation patch accordingly, unless you want to beat me at it. In any case, it is the responsibility of the tool doing the tracing of AC_CONFIG_MACRO_DIR to give a meaningful semantics to its usages (e.g., multiple arguments, several calls, etc), so that aclocal can still be "extra-nice" to our users and support several AC_CONFIG_MACRO_DIR macro calls as well as multiple arguments to AC_CONFIG_MACRO_DIR. The code to do so will be small and trivial anyway. > And should we mention that the first directory listed has special > significance to other tools > Probably yes; for example, "aclocal --install" will install required third-party m4 files in the first directory specified by AC_CONFIG_MACRO_DIR (this is consistent with the semantics of the '-I' option). > like libtool that use the first directory > (and ignore subsequent directories) when first preparing a package with > libtoolize? > Well, if I read the libtoolize source correctly, it will actually use the *last* directory :-( > For that matter, I'd have to investigate whether libtoolize > uses grep or autoconf tracing; > It uses sed :-/ > 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...) > Thanks, Stefano