GNU bug report logs - #11294
[RFC] build: support and require Automake-NG

Previous Next

Full log

Message #14 received at 11294 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11294 <at> debbugs.gnu.org
Subject: Re: 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 <stefano.lattarini <at> gmail.com>
>> ---
>>
>>  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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.