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

[Eric Blake]

On 11/13/2012 02:35 PM, Nick Bowler wrote:
>  (0) Packages have a simple AC_CONFIG_MACRO_DIR([foo]) and a simple
>      ACLOCAL_AMFLAGS = -I foo and don't do anything weird.  I think all
>      of us agree that this is the most common case.

Yep, and it works.

> 
>  (1) Packages that use ACLOCAL_AMFLAGS to specify one or more macro
>      directories and do *NOT* use AC_CONFIG_MACRO_DIR at all.  You
>      agreed earlier that this was a good choice for packages using
>      more than one macro directory.  I suspect it's also quite common
>      in packages that aren't using libtool.  For example, GNU Gettext
>      appears to be in this category.

This will continue to work, although automake may start issuing warnings
about ACLOCAL_AMFLAGS being deprecated.

> 
>  (2) Packages that use a single AC_CONFIG_MACRO_DIR to only to shut up
>      libtool, and specify more than one macro directory in
>      ACLOCAL_AMFLAGS.  You also agreed that this was a reasonable
>      choice for package maintainers who need more than one macro
>      directory.

Reasonable, as long as the one directory they specify matches the first
directory listed in ACLOCAL_AMFLAGS.

Such packages can also add this to configure.ac:
m4_define_default([AC_CONFIG_MACRO_DIRS])
AC_CONFIG_MACRO_DIRS([secondary])

to document the remaining directories in a manner that will work with
autoconf 2.69.  If anything, this would be a useful addition to autoconf
NEWS.

> 
>  (3) Packages that use more than one AC_CONFIG_MACRO_DIR.  You argue
>      that this was broken to begin with.

Correct.

> 
>  (4) Packages that aren't using libtool, tried to do (0), but for
>      whatever reason AC_CONFIG_MACRO_DIR and ACLOCAL_AMFLAGS are out
>      of sync.  You argue that this was broken to begin with.

Correct.

> 
> For simplicity, let's only consider the following scenario: someone
> wants to autoreconf an old package using new (as-yet-unreleased)
> versions of Autoconf, Automake *AND* Libtool.
> 
> * With this patch to Autoconf, I'm not sure how anyone can possibly add
>   support for AC_CONFIG_MACRO_DIR_TRACE to either aclocal or libtoolize
>   without causing Old Way (2) to fail, without an absurd amount of extra
>   complexity and weird behaviour.

With automake 1.14, the package as written will start triggering
warnings in aclocal about ACLOCAL_AMFLAGS being obsolete, along with a
suggestion to update configure.ac to use AC_CONFIG_MACRO_DIRS to specify
the remaining directories.  Automake 1.13 could even go one further by
ensuring that m4_define_default([AC_CONFIG_MACRO_DIRS]) appears in the
automake macro base, so that even if new automake is mixed with old
autoconf, the advice to use AC_CONFIG_MACRO_DIRS won't cause any issues
as long as the user sticks to new automake.

The user can either ignore the warnings and make no change to their
package (things will still work, just noisier), or heed the warnings and
replace ACLOCAL_AMFLAGS with AC_CONFIG_MACRO_DIRS (a two-line cross-file
change) - I don't see how this classes as an absurd amount of extra
complexity and weird behavior.

> 
> * Maintaining support for both Old Ways (1) and (2) implies that
>   we cannot remove the ACLOCAL_AMFLAGS snarfing code from either
>   libtoolize or autoreconf.

Actually, it is libtoolize and aclocal that care about ACLOCAL_AMFLAGS.
 autoreconf looks for it, but only insofar as it passes it on to
aclocal; and if it is missing, then it is up to aclocal to diagnose any
issues, not autoreconf.  With new enough automake, it is not an issue.

Yes, libtool and automake BOTH have to preserve support for
ACLOCAL_AMFLAGS, at least as long as they aim to interoperate with
autoconf 2.69 and older, but that is the burden on those two packages,
and not the thousands of client packages that used the old interfaces
correctly.

> 
> * Since we must keep the ACLOCAL_AMFLAGS snarfing code, it seems that
>   the easiest way to maintain support for Old Ways (0), (1) *AND* (2) is
>   to use the ACLOCAL_AMFLAGS snarfing code if and only if
>   AC_CONFIG_MACRO_DIR_TRACE does not appear in the m4 traces.
>   
>   This solution will *only* work for Old Way (2) if AC_CONFIG_MACRO_DIR
>   does *NOT* cause AC_CONFIG_MACRO_DIR_TRACE to appear in the m4 traces:
>   i.e., this solution is incompatible with this patch to Autoconf.

I disagree.  Remember, condition (2) is that AC_CONFIG_MACRO_DIR and
ACLOCAL_AMFLAGS agree on the primary directory, but that ACLOCAL_AMFLAGS
had additional secondary directories that were not listed in
configure.ac.  If new automake sees AC_CONFIG_MACRO_DIR_TRACE, then it
knows that new autoconf was in use; and can warn the user to add
appropriate AC_CONFIG_MACRO_DIRS() to bring things back into sync before
recommending that ACLOCAL_AMFLAGS be deleted.  Either the user heeds
that advice (possibly by using the m4_define_default trick to still
preserve the ability to bootstrap their package with older autotools) or
ignores it (and continues to get warnings about things being out of sync).

But either way, it boils down to what automake does with the new macro,
and not anything that autoconf needs to change.  That is, until automake
does AC_PREREQ([2.70]), it should ALWAYS check for ACLOCAL_AMFLAGS; and
if present, it should do a sanity check whether the data that is
supposed to be redundant between configure.ac and Makefile.am is
actually redundant.  If the data is out of sync, then the best course of
action is to support the union of the two specifications, along with
warning the user how to fix things.  And if the data is in sync, warn
the user that they can delete ACLOCAL_AMFLAGS.  If ACLOCAL_AMFLAGS is
absent, then AC_CONFIG_MACRO_DIR_TRACE is the sole source of correct
information.

> 
>   And for bonus points, notwithstanding any arguments that (3) and (4)
>   are not worth caring about, this solution trivially maintains support
>   for (3) and (4) anyway at no additional charge.

If I understand your argument correctly, you are claiming that
AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE,
so that case (2) can be distinguished by automake; but that would mean
that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and
AC_CONFIG_MACRO_DIR for case (0) to work.  But I'm arguing that since
case (2) already implies that things are in sync, that merely comparing
the trace against ACLOCAL_AMFLAGS is sufficient to tell if the user has
updated their package, and if not, then ACLOCAL_AMFLAGS is still trusted
for specifying secondary directories, as it has been done with older
autotools.

> 
> [...]
>> 4. Upgrade everything, but don't rewrite configure.ac
>> Things continue to work as they have
> 
> I don't believe this is the case.  See above.

Only for case (3) and (4), but we agreed that those were already broken.

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

signature.asc
Description: OpenPGP digital signature