autoconf-patches
[Top][All Lists]
Advanced

[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: Eric Blake
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument
Date: Wed, 04 Jul 2012 05:03:02 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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