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

[Eric Blake]

On 11/13/2012 02:37 PM, Nick Bowler wrote:
> On 2012-11-13 22:37 +0200, Adrian Bunk wrote:
>> On Tue, Nov 13, 2012 at 02:44:08PM -0500, Nick Bowler wrote:
>>> On 2012-11-13 20:51 +0200, Adrian Bunk wrote:
>>>> libtool will access the same information through a new way that has been 
>>>> implemented by this patch.
>>>
>>> But the old way will have to stick around for compatibility with older
>>> packages that have not been updated to the New Way.  So since we have to
>>> keep the old way around anyway, why not just continue to use the old way
>>> for old packages?
>>> ...
>>
>> Wrong.
>>
>> libtool does not have to support the old way of manually searching for 
>> AC_CONFIG_MACRO_DIR in the future, if it requires autoconf >= 2.70 it
>> can use the new way of tracing AC_CONFIG_MACRO_DIR_TRACE exclusively 
>> even for old packages.
> 
> No, it cannot use AC_CONFIG_MACRO_DIR_TRACE exclusively, since not all
> packages use AC_CONFIG_MACRO_DIR in the first place!

You are correct that new libtool and automake cannot rely exclusively on
the new trace macro, but that's not a problem and doesn't change
anything we've done in autoconf.

If AC_CONFIG_MACRO_DIR_TRACE has a trace hit, then autoconf 2.70 is in
effect.  Either the configure.ac used AC_CONFIG_MACRO_DIR (old-style)
(and you can assume ACLOCAL_AMFLAGS will exist and match), or it used
AC_CONFIG_MACRO_DIRS (new-style) (and ACLOACL_AMFLAGS is no longer
required), but either way, this is the canonical location to be used.
Automake 1.13 will error out if ACLOCAL_AMFLAGS exists but does not
match the trace (thus enforcing that _if_ you use the redundancy, you
use it correctly); but will not care if you omit ACLOCAL_AMFLAGS.

If AC_CONFIG_MACRO_DIR_TRACE has no trace hit, then there are two
possibilities:
1. autoconf 2.69 is in use, so the new trace point didn't exist.  In
this case, we trace AC_CONFIG_MACRO_DIR instead.  Either it hits (and we
proceed with the same logic as if AC_CONFIG_MACRO_DIR_TRACE had a hit)
or it misses (and we proceed with the same logic of ACLOCAL_AMFLAGS
fallback).

2. autoconf 2.70 is in use, but the user did not call
AC_CONFIG_MACRO_DIR.  In that case, we do the ACLOCAL_AMFLAGS fallback.
 If that line is still present in Makefile.am, then we rely on it for
determining the primary directory (and warn the user to add
AC_CONFIG_MACRO_DIR to configure.ac); if it is missing, then we don't
know where the primary directory is for installing macros (and error out
accordingly).

So yes, if there are no trace hits on the new macro, then new code must
be prepared to look in old locations.  But that is a task for libtool
and automake (as the packages that care about the trace results), not
autoconf (which cares nothing about the result other than that it could
be traced), so arguing about it on this list won't change what needs to
be done to use the new trace macro.  And in fact, that's already what
Stefano did for automake: note how he specifically favors the new trace
if present (and ignores the old trace in that case); but when the new
trace is not present, then he falls back to the old trace:
https://lists.gnu.org/archive/html/automake-patches/2012-11/msg00048.html
Furthermore, the fallback of supporting the old trace is needed only so
long as automake doesn't do AC_PREREQ([2.70]).  If automake makes that
prerequisite a requirement, then absence of the new trace means that the
user did not specify a directory at all in configure.ac, by either spelling.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature