autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks


From: Eric Blake
Subject: Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks
Date: Mon, 12 Nov 2012 16:09:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2

On 11/12/2012 03:41 PM, Nick Bowler wrote:
> Sorry, I don't understand.  You seem to be claiming that the addition of
> AC_CONFIG_MACRO_DIRS (an entirely new macro, with documented behaviour)
> to Autoconf will somehow break the following pattern if we don't also
> change the definition of AC_CONFIG_MACRO_DIR?
> 
>   configure.ac:
>   AC_CONFIG_MACRO_DIR([foo])
> 
>   Makefile.am:
>   ACLOCAL_AMFLAGS = -I foo
> 
> What breaks?  How does it break?  Why will this not continue to work

For this usage, nothing breaks.  It continues to work as it has done
(well, new enough automake might start complaining about your use of
obsolete ACLOCAL_AMFLAGS, but that's not autoconf's fault).  The key is
that you used AC_CONFIG_MACRO_DIR only once in this example, so it will
continue to function, because there is no ambiguity.

> exactly as it has in the past if we do not keep AC_CONFIG_MACRO_DIR's
> definition exactly as it is right now, i.e.:
> 
>   AC_DEFUN([AC_CONFIG_MACRO_DIR], [])

This definition is one way of spelling 'no effect except for use by
tracing'.  Another way of spelling 'no effect except for use by tracing'
is the one now in autoconf.git, but where the tracing now goes through
the AC_CONFIG_MACRO_DIR_TRACE macro, and where we have imposed an
interaction with the brand-new macro (if you mix the old and new macro,
then the old macro must be used first, to avoid ambiguity).

> Another thing to consider is that, if you aren't using libtool, the
> following will work fine today, too (and I think will be totally broken
> by this change):
> 
>   configure.ac:
>   AC_CONFIG_MACRO_DIR([somewhere-else])
> 
>   Makefile.am:
>   ACLOCAL_AMFLAGS = -I m4

Using today's tools, this is ambiguous - you are specifying _different_
information between two points that are _supposed_ to be redundant in
older autotools.  Therefore, all bets are off on what final behavior you
get, but in this case, the final behavior will depend more on which
libtool and/or automake version you are using, not what autoconf version
you are using.  Furthermore, the redundancy requirements ARE documented
in the autoconf 2.69 manual, under AC_CONFIG_MACRO_DIR, along with a
promise that someday ACLOCAL_AMFLAGS will disappear.  Well, someday is
nearly here: autoconf 2.70 and automake 1.14 will get rid of the need
for ACLOCAL_AMFLAGS and thus the redundancy, and therefore avoid the
confusion that was possible if you put conflicting information between
the two sites.

The ONLY thing that will explicitly error out if you use older libtool
and autoconf 2.70 is if you use AC_CONFIG_MACRO_DIR twice; but that is
already an unusual usage pattern, and another instance of redundancy and
confusion (since no one documented that libtool's use of
AC_CONFIG_MACRO_DIR in printing a warning message used a different order
than automake's usage of ACLOCAL_AMFLAGS).

-- 
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]