[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [PATCH] build: support and require Automake-NG
Date: Tue, 21 Aug 2012 12:20:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0

Il 21/08/2012 12:10, Stefano Lattarini ha scritto:
>>> 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 definition.
> I agree.  And in fact this is exactly the mechanism provided by Automake-NG!

Doh, obvious when you point it out. :)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]