[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument

From: Stefano Lattarini
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument
Date: Wed, 04 Jul 2012 13:37:34 +0200

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:
>> <>
>> <>
>> * 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:
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 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...)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]