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: > > 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;
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:
- /AC_CONFIG_MACRO_DIR(/ {
- 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
(yuck).
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:
AC_CONFIG_MACRO_DIR([dir1])
AC_CONFIG_MACRO_DIRS([dir2 dir3])
AC_CONFIG_MACRO_DIRS([dir4])
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 ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
