[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11294: [RFC] build: support and require Automake-NG
From: |
Jim Meyering |
Subject: |
bug#11294: [RFC] build: support and require Automake-NG |
Date: |
Tue, 08 May 2012 21:57:40 +0200 |
Stefano Lattarini wrote:
> On 04/21/2012 11:48 AM, Stefano Lattarini wrote:
>> * configure.ac (AM_INIT_AUTOMAKE): 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.11e', which is
>> the latest (and still development-only) version of Automake-NG at the
>> moment of writing.
>> * bootstrap (check_versions): Hacked to handle automake and aclocal
>> from Automake-NG specially. This change should be backported to Gnulib
>> proper in a later step.
>> * bootstrap.conf ($buildreq): Require "automake-ng" and "aclocal-ng"
>> version >= 0.5; don't require mainstream "automake" anymore.
>>
>> Signed-off-by: Stefano Lattarini <address@hidden>
>> ---
>>
>> I'd like this to be applied to an experimental branch in the coreutils
>> repository, which will be used to test and experiment with Automake-NG
>> in a real-world, important, medium-complexity package like GNU coreutils
>> is.
>>
>> I hope you'll agree this is a sensible move, which could bring advantages
>> and improvements to both coreutils and Automake-NG.
>>
> I've updated the patch to take into account:
>
> - the recent bump in the Automake-NG version (1.11e => 1.12a);
> - the bump in the minimal Autoconf version required by Automake-NG
> (2.62 => 2.65);
> - the support for Automake-NG recently added to the Gnulib-provided
> bootstrap script
> - the removal of the m4 macro 'AM_PROG_MKDIR_P' from the master
> branch of the Automake repository (and thus from Automake-NG,
> where 'master' is regularly merged).
>
> So, OK to apply this patch to a new branch in the coreutils official
> repository? Or it's better if I clone the coreutils repo on GitHub
> and work there, to have more freedom while experimenting?
Hi Stefano,
The git commit hooks that we use (e.g., to prohibit pushing merge commits)
might well slow you down: I presume they'd have to be adjusted to permit
merge commits or non-ff messiness) on that new branch.
As you suggest, using another repository may be better.