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

[Stefano Lattarini]

On 11/13/2012 11:41 PM, Eric Blake wrote:
>
> [SNIP]
>
>>  (3) Packages that use more than one AC_CONFIG_MACRO_DIR.  You argue
>>      that this was broken to begin with.
> 
> Correct.
>
I agree.  We don't want to support several calls to AC_CONFIG_MACRO_DIR,
nor calls to AC_CONFIG_MACRO_DIR specifying more than one directory.
That was never documented to be supported anyway.

> [SNIP]

>>
>> 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.
>
That is a good idea.  It could be put in 'm4/init.m4'.

> 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.
>
Nope, Nick was right: ACLOCAL_AMFLAGS is processed by autoreconf, but
not by aclocal.  So far, the only use of ACLOCAL_AMFLAGS in aclocal and
automake has been in the automatic rebuild rules for aclocal.m4 (see
'lib/am/configure.am' in the Automake source tree).

> autoreconf looks for it, but only insofar as it passes it on to
> aclocal;
>
Ah, OK, so you knew it already.  Unsurprising ;-)

> and if it is missing, then it is up to aclocal to diagnose any
> issues, not autoreconf.
>
I agree it's not autoreconf business to diagnose such issues; but
neither is aclocal's.  If anything, it should be automake that
should do such diagnosis, since, as I've said, it's only automake
generated rebuild rules that make use of ACLOCAL_AMFLAGS.

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

>>
>> * 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,
>
That already happen automatically in the rebuild rules (with the
directories in ACLOCAL_AMFLAGS taking precedence, as they end up
being specified on the command line); and we get this for free,
without any need to touch the pre-existing code.

> along with warning the user how to fix things.
>
This is not yet implemented.

> And if the data is in sync, warn the user that they can delete
> ACLOCAL_AMFLAGS.
>
Unless they still use '--install' there.  Making up for the removal
of that will require tightening the "distcheck" rule; something for
Automake 1.14.  For more background, see:

  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9037>

> 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.
>
Currently, Automake is already tracing both AC_CONFIG_MACRO_DIR and
AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages.  Are
you arguing that tracing both macros is a bad idea?  If yes, I might
add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and
AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detected, so that
packages using older autoconf but newer aclocal/automake will still be
able to rely on that macros.  And this hack will be removed in Automake
1.14 (when we'll start requiring autoconf 2.70), so this clumsy extra
code won't pollute our codebase for too long.

Opinions?

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

Regards,
  Stefano