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

[Nick Bowler]

On 2012-11-12 11:24 -0700, Eric Blake wrote:
> On 11/12/2012 08:42 AM, Nick Bowler wrote:
> > On 2012-11-09 15:53 -0700, Eric Blake wrote:
> > If the goal is compatibility with existing behaviour of libtool,
> > then we must allow multiple invocations of AC_CONFIG_MACRO_DIR and
> > they must emit AC_CONFIG_MACRO_DIR_TRACE in the reverse order.
> 
> No, existing use of libtool was intended to honor only the first
> AC_CONFIG_MACRO_DIR, but due to a bug, actually honored only the last.
> It does NOT honor multiple directories, so anyone actually _using_
> AC_CONFIG_MACRO_DIR with existing libtool could only successfully use it
> once.  The new code in autoconf enforces that usage, since anything else
> is confusing.

Regardless of what was intended, what actually happened was that libtool
only looked at the last AC_CONFIG_MACRO_DIR.  As libtool never documented
its behaviour either way, we should strive to avoid breaking things by
not making arbitrary changes to longstanding behaviour.

Saying that, I wish to amend my original statement.
AC_CONFIG_MACRO_DIR_TRACE shouldn't be output in the reverse order of
AC_CONFIG_MACRO_DIR invocations: it should be output only for the last
such invocation.

> >>From the look of things, this patch intentionally breaks such
> > invocations, which currently work (since AC_CONFIG_MACRO_DIR
> > doesn't do anything).
> 
> Yes, it DOES do something - it tells libtool where to install files, and
> libtool needs to install files in the FIRST directory, not the last.  So
> this change is indeed intentional.

Sort of.  As far as I can tell it only tells libtoolize whether or not
to print a warning: not where to install files.  Libtoolize snarfs in
ACLOCAL_AMFLAGS regardless of whether or not AC_CONFIG_MACRO_DIR is
used.

Nevetheless, Libtool doesn't need to install to the first directory: it
needs to keep doing what it always has been doing so that things don't
regress.

> We haven't done anything to this macro except for hardening it up to
> detect invalid usage.

It is not the case that this "hardening" (I would call it "breaking" or
"regressing", but whatever) is the only change that this patch makes to
this macro.  You've also made it interoperate with AC_CONFIG_MACRO_DIRS
(a totally new feature) in a manner that is specified as being different
from its previous observable behaviour.

> > No released version of libtool requires AC_CONFIG_MACRO_DIR to be
> > used in configure.ac.
> 
> Yes it does - libtoolize warns noisily if you didn't use
> AC_CONFIG_MACRO_DIR in configure.ac, so people have been adding it
> because of libtool's warnings.

This warning is a far cry from *requiring* its use in configure.ac.

Here's the thing: suppose a libtool-using package is using
any currently-released versions of the autotools, and needs the
equivalent of:

  ACLOCAL_AMFLAGS = -I foo -I bar

With this, libtoolize warns about missing AC_CONFIG_MACRO_DIR([foo]).
Now the package maintainer essentially has three options:

  (1) Ignore the warning, and do not add any AC_CONFIG_MACRO_DIR to
      configure.ac.
  (2) Add AC_CONFIG_MACRO_DIR([foo]) to configure.ac, ignore bar.
  (3) Add AC_CONFIG_MACRO_DIR([bar]) and AC_CONFIG_MACRO_DIR([foo]) to
      configure.ac, in that order.

Of the three, option (2) is pretty unattractive since it requires
admitting that AC_CONFIG_MACRO_DIR is useless, so you may as well go
with (1) in that case.  That pretty much leaves (1) and (3) as viable
options.

And this is not hypothetical: this is exactly what I went through
with my own packages.  I ended up choosing option (1) and removed
AC_CONFIG_MACRO_DIR from everything, but I could see a reasonable
person choosing option (3) to silence the warnings.  All of these
options currently work: your change breaks (3) and I suspect (2)
will break later if we try to "help" and make AC_CONFIG_MACRO_DIR
useful.

> >  Any package targeting compatibility with as-yet-
> > unreleased versions of automake (read: such packages are by definition
> > new developments) and old versions of libtool can simply elide the
> > macro from their configure.ac, and things will work.
> 
> Yes, they will work (because the message from libtool was a warning, not
> an error), but silence is better than warnings.  Hence my goal of
> allowing the macro to continue to be used in a manner which will shut up
> older libtoolize warnings.

Gratuitous fatal errors introduced by this change are worse than both
silence and warnings.  If all you want is to silence the libtool
warnings with old versions, then I would actually suggest the following:

  dnl Shut up libtoolize
  m4_ignore([AC_CONFIG_MACRO_DIR([m4])])

which also works, and doesn't require any help from Autoconf.

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