Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

[Eric Blake]

On 02/02/2013 01:40 AM, Stefano Lattarini wrote:
>> I subscribe to all the good opinions about NG that have been
>> made here.  I would definitely use it once there is a release
>> (I have already been criticized several times for having used
>> then-CVS versions of the Autotools in Bison, and I don't want
>> to go in that direction again).
>>
> Oh, but I wasn't suggesting to use Automake-NG to bootstrap an official
> GNU package!

Why not?  The end product tarball will require GNU make, but other than
that, the end user won't care whether automake or Automake-NG was used
to create the tarball.  Besides, it is already possible to use automake
in a manner that requires GNU make, so end users of those packages won't
notice a difference.

I guess where it might matter is if distros try to rerun Automake-NG as
aggressively as they try to rerun automake on existing packages.
Existing distros have stacked the autotools so that they can rerun the
same version of automake as a package was originally built with, even if
a newer automake has been released since then.  So if Automake-NG
releases are breaking backwards compatibility for the first little while
due to being at alpha quality, that implies that distros will have to
repeat their efforts on providing a stacked Automake-NG release for any
cases where a package needs to be re-autotooled as part of the distro
process.

On the other hand, most of the cases where distros end up relying on
stacked automake is for packages that aren't actively maintained
upstream, and therefore need to have their configure.ac and Makefile.am
patched downstream.  It can be assumed that the early adopters of
Automake-NG are still active, and will be released frequently enough,
that it will be easier to fix issues upstream and re-release than to
make the distros have to carry downstream patches against configure.ac
and Makefile.am that require rerunning the autotools as part of the
distro process.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature