Re: [PATCH] build: support and require Automake-NG

[Paolo Bonzini]

Il 21/08/2012 12:10, Stefano Lattarini ha scritto:
>>> (AC_SUBST): Define AM_VARTYPOS_WHITELIST to "LIBFFI_EXECUTABLE_LDFLAGS
>>> RELOC_LDFLAGS".  This is required because Automake-NG is stricter than
>>> mainline Automake in its make runtime checks on possible typos in
>>> variables like 'foo_SOURCES' and 'bar_LDADD', and that was causing a
>>> spurious failure in the GNU Smalltalk build system.
>>
>> Can Automake-NG instead whitelist all-uppercase variables?
>>
> I'd rather not add extra special cases unless that proves to be actually
> necessary.  And I believe that is not the case here, since the white
> listing is obtained with just a simple one-liner.
> 
> If you really don't like the whitelisting, another viable solution would
> be to rename the RELOC_LDFLAGS variable to, say, RELOC-LDFLAGS, or even
> LDFLAGS.RELOC; and similarly for the other variable.  This is the solution
> I'd personally prefer; in the I sent patch I opted for the whitelisting
> just because that entailed less code churn.

The point is not the whitelisting; it is really that zero code churn is
still the best choice...  This smells too much of Autoconf 2.50...  I
was there and it was not pretty. ;)

Another choice is to find AC_SUBSTed variables that end with LDFLAGS,
CPPFLAGS, CFLAGS, etc., and whitelist them automatically.  It can be
done in m4, from Automake-NG's macros.

>> Also, this is different from all other configuration mechanisms; it
>> would be nicer to have it as an Automake-provided AM_* macro,
>>
> Nope, because the whitelisting must be allowed to be Makefile-specific.
> 
>> or a Makefile.am definition.
>>
> I agree.  And in fact this is exactly the mechanism provided by Automake-NG!

Doh, obvious when you point it out. :)

>>> * Makefile.am (AUTOMAKE_OPTIONS): Add the 'ng' option, to ensure that
>>> mainstream Automake is not used by mistake when bootstrapping.  Also,
>>> bump the required Automake version from '1.11.1' to '1.12a', which is
>>> the latest (and still development-only) version of Automake-NG at the
>>> moment of writing.  Drop the 'dist-xz' option, that is not supported
>>> anymore.  The same effect is now obtained ...
>>> (AM_DIST_FORMATS): ... defining this to "gzip xz".
>>
>> Can you instead provide the  backwards-compatible format with a
>> deprecation period?
>>
> No, sorry, that would complicate the Automake-NG code for too little
> gain.  Automake-NG is actually about "maintainer convenience" as much
> as it is about "user convenience", so such backward-incompatibilites
> and little porting efforts are to be expected when switching from
> mainline Automake to Automake-NG.

That's fine, indeed if you add support in mainline Automake the
deprecation period would end with the merge of Automake-NG.

>> And perhaps add support for AM_DIST_FORMATS in mainline Automake?
>>
> This should be easily doable for 1.13, or even 1.12.4.  And it might
> help some projects simplifying their transition to Automake-NG.  So
> why not?  I'll try to cook up a patch in the next days.

Nice.

Paolo