[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
Date: Sat, 02 Feb 2013 08:03:44 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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

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 and
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
and that require rerunning the autotools as part of the
distro process.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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