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

[Nick Bowler]

On 2012-11-13 15:41 -0700, Eric Blake wrote:
> 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.
[snipping all commentary on the list of cases]
> >  (1) Packages that use ACLOCAL_AMFLAGS to specify one or more macro
> >      directories and do *NOT* use AC_CONFIG_MACRO_DIR at all.
[...]
> >  (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.
[...]
> >  (3) Packages that use more than one AC_CONFIG_MACRO_DIR.
[...]
> >  (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.
[...]
> 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;

Yes, exactly.

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

I don't think tracing AC_CONFIG_MACRO_DIR in case (0) would be
necessary: it can be ignored since the appropriate directory will be
picked up from ACLOCAL_AMFLAGS.

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

So I'm willing to concede on case (3) as not being worth worrying about.
Now that I've thought about it more, I think there's actually an even
simpler solution, compatible with this patch, that will easily maintain
backwards compatibility with cases (0), (1), (2).  You won't even need
to do any comparisons of the trace against ACLOCAL_AMFLAGS.

It will also work with case (4) (OK, it will fail with some really
contrived corner cases) if tools merely *warn* about garbage arguments
to AC_CONFIG_MACRO_DIR instead of making it a fatal error.

All that needs to happen, I think, is this:

 * aclocal looks for AC_CONFIG_MACRO_DIR_TRACE in the m4 traces, and
   unconditionally adds them to the macro search path.

 * aclocal ensures that any directories specified by -I options on the
   command line are searched *prior* to anything found in the m4 traces.

   This might actually be the current state of affairs, but I don't see
   anything in the Automake manual about the interaction between -I
   options and AC_CONFIG_MACRO_DIRS.

 * libtoolize uses the first AC_CONFIG_MACRO_DIR_TRACE if available,
   otherwise it falls back to snarfing ACLOCAL_AMFLAGS.

and I think the rest is status quo:

 * autoreconf snarfs ACLOCAL_AMFLAGS and, if it's present, passes it to
   aclocal on the command line, just like it currently does. This is
   done unconditionally.

 * automake continues to emit rebuild rules which unconditionally
   reference $(ACLOCAL_AMFLAGS), just like it currently does.

This should all work because in the cases we agree are important, (0),
(1) and (2), the use of AC_CONFIG_MACRO_DIR is always redundant since
the macro directory appears in the correct spot in ACLOCAL_AMFLAGS.

And since there should be no harm in having the first macro directory
appear more than once in the search path, nothing should break.

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