Automake vs. Automake-NG (was: Re: [PATCH] build: support and require Automake-NG)

[Stefano Lattarini]

On 08/21/2012 12:20 PM, Paolo Bonzini wrote:
> 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. ;)
>
But there is an important difference: Automake-NG is *not* the next
version of Automake, it is the "Next Generation": it's not meant to
be merged into the Automake code base, nor to supersede Automake,
because the two projects have different "mission statement":

  - Automake: allow the user to write Makefiles portable to different
    systems *and* make implementation, and help him to *avoid* using
    GNU make specific features would hurt portability,

  - Automake-NG: allow the user to write Makefiles portable to
    different systems *but* tailored for modern GNU make, and allow
    them to take *full advantage* of GNU make features whenever
    possible (which is less than we'd like, due to the code base
    and design inherited from mainline Automake).

Automake-NG might finally supersede Automake when *and if* the great
majority of developers using the the Autotools agree that porting to
non-GNU make is not worth anymore; but that will not mean that
Automake has been merged into Automake-NG, merely that a change in
portability requirements have made it obsolete.  That's very important
to understand.

> 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.
>
I'm still not sold on this.  What if a user have "foobar" in
bin_PROGRAMS, and then do something like this in its configure.ac:

  if something; then
    AC_SUBST([foobar_LDFLAGS], [-lzap])
  else
    AC_SUBST([foobaz_LDFLAGS], [-lmu])
  fi

I think a warning about "no program or library named 'foobaz'" is
still warranted here.

>>> 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.
>
But, as I've stressed above, Automake-NG is *not* going to be merged
in mainline Automake, ever.  The fork has not been thought with that
aim in mind.  The two projects are meant to co-exists as long as there
still are significant client packages that wants to work with non-GNU
make implementations (and thus need mainline Automake); when *and if*
this portability requirement is finally dropped, Automake will just
be abandoned -- not subsumed, not explicitly obsolete; we'll just stop
developing and bug-fixing it.

>>> 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.
>
(Or I'll accept one, if someone want to beat me at it ;-)

> Nice.
> 
> Paolo
> 

Hope I've clarified the situation a bit.

Regards,
  Stefano