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

On 07/04/2012 05:03 AM, Eric Blake wrote:

> Would it also make sense to allow multiple calls to AC_CONFIG_MACRO_DIR
> to stack, as in:
> 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;

Libtool 2.4.2 (the current release) uses grep tracing; but libtool
commit 2a71b02b has already converted over to m4 tracing.  I'm not sure
if the m4 tracing will gracefully handle whitespace-separated
directories or multiple invocations, but the old code:

-       s,^.*AC_CONFIG_MACRO_DIR([[  ]*\([^])]*\).*$,ac_macro_dir=\1,
-       p
-        }

definitely does NOT handle whitespace lists, and with multiple calls,
appears to reassign $ac_macro_dir to the last call rather than the first

I think we're stuck for compatibility with providing a new macro for
listing subsidiary directories, and that users that plan to interact
with old libtool must use something like:


where the new macro can stack or take whitespace lists.  The new macro
can also auto-call AC_CONFIG_MACRO_DIR() for its first argument for new
libtool that traces rather than using sed, but if you are porting to
older libtool, explicitly spelling out the old name is important.

Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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