Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks

From: Eric Blake <[email-masked]>
Date: Tue, 13 Nov 2012 13:39:13 -0700

On 11/13/2012 01:16 PM, Stefano Lattarini wrote:
>> 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?  This has the advantage of both not breaking any
>> existing packages, and not breaking any of the examples I've provided so
>> far.
>>
>> Packages that update to the New Way will gain access to the new
>> features, while packages that have not yet updated will continue to work
>> exactly as they did before... AND even my most contrived examples of how
>> things can be broken by this change will continue to work as they always
>> have.  Is that not the best option?

The best option is that a package that uses the old way will work with
new tools.  And this is what we've done.  That means:

I write a configure.ac with a single AC_CONFIG_MACRO_DIR([dir]) AND a
redundant ACLOCAL_AMFLAGS=-I dir.  Old libtool uses 'dir' to decide
whether to print a warning, and old autoreconf and aclocal just use
ACLOCAL_AMFLAGS.

Then, with that same configure.ac, I have several upgrade paths:

1. New autoconf, old automake and old libtool
Autoreconf now sniffs AC_CONFIG_MACRO_DIR_TRACE instead of
ACLOCAL_AMFLAGS for deciding what to pass to aclocal.  No big deal - the
two are already equivalent.  Libtool and aclocal continue to work as
they always have.

2. New automake, old autoconf and old libtool
Automake now pays attention to AC_CONFIG_MACRO_DIR_TRACE, and can now do
a sanity check that the first traced directory (dir) matches what is in
ACLOCAL_AMFLAGS when that is present.  Automake may choose to warn that
ACLOCAL_AMFLAGS is deprecated, but things will still work.  Libtool and
autoconf continue to work as they always have.
With this option, if you WANT to document secondary directories, but
still allow another developer to bootstrap your package without
upgrading automake, then you can add:
m4_define_default([AC_CONFIG_MACRO_DIRS])
AC_CONFIG_MACRO_DIRS([secondary])
But such documentation should be redundant with the ACLOCAL_AMFLAGS that
remains for use of old libtool and autoreconf.

3. New libtool, old autoconf and old automake
Libtool now pays attention to AC_CONFIG_MACRO_DIR_TRACE, and continues
to do a sanity check that it matches ACLOCAL_AMFLAGS when that is
present.  Autoconf and automake continue to work as they always have.

4. Upgrade everything, but don't rewrite configure.ac
Things continue to work as they have

5. Upgrade everything, and decide that I no longer need to cater to
older tools
Edit configure.ac to AC_PREREQ([2.70]) and request automake 1.13 and the
next libtool version
Also edit configure.ac to use AC_CONFIG_MACRO_DIRS instead of
AC_CONFIG_MACRO_DIR; at this point, you can finally list secondary
directories
Also edit Makefile.am to ditch ACLOCAL_AMFLAGS

>>
>> Cheers,
>>
> I must say I find Nick's arguments quite compelling by now.
> 
> Eric, could we just deprecate AC_CONFIG_MACRO_DIR (in the documentation
> only for the moment, at least for a couple of releases), and point the
> users to AC_CONFIG_MACRO_DIRS exclusively?  Or is there some reason not
> to do so that both I and Nick are missing?

We _DID_ that.  We documented that AC_CONFIG_MACRO_DIR is only around
for back-compat reasons, and that if you use it, it must come first, and
that AC_CONFIG_MACRO_DIRS provides everything else; but that if you are
willing to assume new tools across the board, then you can ditch
AC_CONFIG_MACRO_DIR, ditch ACLOCAL_AMFLAGS, and exclusively use
AC_CONFIG_MACRO_DIRS.

> 
> If Eric is OK with such a change, once it's done I'll also revert the
> aclocal's support for AC_CONFIG_MACRO_DIR (present only in the master
> branch so far, and not in any released automake versions, so no worries
> about backward compatibility there).

So far, you haven't convinced me that anything needs changing, beyond
what we've already done.  As far as I can tell, you are arguing that
packages that use multiple AC_CONFIG_MACRO_DIR should continue to
silently work, with confusing documentation rules, rather than autoconf
flag that as suspicious usage; but that is independent of whether a
single use of AC_CONFIG_MACRO_DIR will work.  And if that is what you
are proposing, then patches welcome.

> 
> BTW: Nick, if it suits you, would you care to post a shorter,
> self-contained rationale summarizing your points so far?  So
> you'll finally convince us completely -- and we'll shamefully
> steal that rationale for our commit messages ;-)

Indeed - I still haven't been convinced that we've broken anything that
wasn't already broken (namely, the rare package that uses
AC_CONFIG_MACRO_DIR more than once).  But if causing a hard error if
AC_CONFIG_MACRO_DIR multiple times is what is bothering you, then
perhaps it is a one-liner patch to turn it into a warning instead of an
error.

-- 
Eric Blake   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org