[Top][All Lists]
[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
- Re: [PATCH] build: support and require Automake-NG,
Stefano Lattarini <=
- Re: [PATCH] build: support and require Automake-NG, Paolo Bonzini, 2012/08/21
- Automake vs. Automake-NG (was: Re: [PATCH] build: support and require Automake-NG), Stefano Lattarini, 2012/08/21
- Re: Automake vs. Automake-NG, Paolo Bonzini, 2012/08/21
- Re: Automake vs. Automake-NG, Stefano Lattarini, 2012/08/21
- Re: Automake vs. Automake-NG, Diego Elio Pettenò, 2012/08/21
- Re: Automake vs. Automake-NG, Paolo Bonzini, 2012/08/21
- Re: Automake vs. Automake-NG, Diego Elio Pettenò, 2012/08/21
- Re: Automake vs. Automake-NG, Stefano Lattarini, 2012/08/21
- Re: Automake vs. Automake-NG, Stefano Lattarini, 2012/08/21
- Re: Automake vs. Automake-NG, Paolo Bonzini, 2012/08/21