automake
[Top][All Lists]
Advanced

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

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


From: Stefano Lattarini
Subject: Re: [PATCH] build: support and require Automake-NG
Date: Tue, 21 Aug 2012 12:10:55 +0200

[Adding the Automake and Automake-NG lists in CC]

Reference:
<http://lists.gnu.org/archive/html/help-smalltalk/2012-08/msg00032.html>

On 08/21/2012 11:28 AM, Paolo Bonzini wrote:
> Il 21/08/2012 11:22, Stefano Lattarini ha scritto:
> 
> Cool, let's look at it one by one.
> 
>> * configure.ac (AC_PREREQ): Require Autoconf version >= 2.65,
>> since that is the minimal version supported by Automake-NG.
> 
> This is good.
> 
>> (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.

> 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!
It's just that, in Automake-NG as in mainline Automake, definitions of make
variables can also be specified through AC_SUBST calls, which is very handy
in case those definitions must be propagated in all the Makefile.am files
of the project -- as is the case here.  If you don't mind duplication, you
could simply copy the

  AM_VARTYPOS_WHITELIST = LIBFFI_EXECUTABLE_LDFLAGS RELOC_LDFLAGS

definition by hand in all the affected Makefiles.  As you prefer.

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

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

>> * .gitignore: Ignore all the '.am/' directories everywhere; it's
>> used internally by some Automake-NG generated rules.
>> * build-aux/.gitignore: Ignore the 'am-ng/' directory; it's used by
>> Automake-NG to install makefile fragments used by its generated
>> Makefiles.
> 
> This is not a problem, of course.
> 
> Paolo

Thanks,
  Stefano



reply via email to

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