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

From: Nick Bowler <[email-masked]>
Date: Tue, 13 Nov 2012 16:35:38 -0500

On 2012-11-13 13:39 -0700, Eric Blake wrote:
> 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.

As I have already said, this is not the only "Old Way".  I have never
argued that this case was problematic, so I don't know why you are
bringing it up in your example.  Nevertheless, here are five specific
possibilities, all of which I have mentioned already.  All of these
possibilities work with the latest versions of autoconf, automake and
libtool, and I would expect (but have not tested) them to work with
pretty much any combination since autoconf-2.57g.

 (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.

 (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.

 (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.

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

 (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.

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.

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

* 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.

  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.

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

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)