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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11294 in the body.
You can then email your comments to 11294 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-coreutils <at> gnu.org
Cc: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: [RFC] build: support and require Automake-NG
Date: Sat, 21 Apr 2012 11:48:03 +0200

* 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.

 Regards,
   Stefano

 bootstrap      |   19 +++++++++++++++++++
 bootstrap.conf |    3 ++-
 configure.ac   |    2 +-
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/bootstrap b/bootstrap
index c8ee3cc..cc058bd 100755
--- a/bootstrap
+++ b/bootstrap
@@ -429,6 +429,25 @@ check_versions() {
         GZIP) ;; # Do not use $GZIP:  it contains gzip options.
         *) eval "app=\${$appvar-$app}" ;;
     esac
+
+    # Special handling for Automake-NG programs.  They are still named as
+    # the mainstream Automake programs ("automake", "aclocal") to avoid
+    # gratuitous incompatibilities with pre-existing usages (by, say,
+    # autoreconf, or custom autogen.sh scripts), but correctly identify
+    # themselves (as being part of "GNU automake-ng") when asked their
+    # version.
+    case $app in
+    automake-ng|aclocal-ng)
+      app=`echo "$app" | sed 's/-ng$//'`
+      if ($app --version | grep '(GNU automake-ng)') >/dev/null 2>&1; then
+        :
+      else
+        echo "$me: Error: '$app' not found or not from Automake-NG" >&2
+        ret=1
+        continue
+      fi ;;
+    esac
+
     if [ "$req_ver" = "-" ]; then
       # Merely require app to exist; not all prereq apps are well-behaved
       # so we have to rely on $? rather than get_version.
diff --git a/bootstrap.conf b/bootstrap.conf
index bb414ef..a2432aa 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -307,8 +307,9 @@ gnulib_tool_option_extras="--tests-base=gnulib-tests --with-tests --symlink\
 
 # Build prerequisites
 buildreq="\
+automake-ng -
+aclocal-ng  -
 autoconf   2.62
-automake   1.11.1
 autopoint  -
 bison      -
 gettext    0.17
diff --git a/configure.ac b/configure.ac
index 5a4860e..dab8b07 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,7 @@ AC_CONFIG_SRCDIR([src/ls.c])
 AC_CONFIG_AUX_DIR([build-aux])
 AC_CONFIG_HEADERS([lib/config.h:lib/config.hin])
 
-AM_INIT_AUTOMAKE([1.11.1 no-dist-gzip dist-xz color-tests parallel-tests])
+AM_INIT_AUTOMAKE([1.11e ng no-dist-gzip dist-xz color-tests parallel-tests])
 AM_SILENT_RULES([yes]) # make --enable-silent-rules the default.
 
 dnl POSIXCHECK is worthwhile for maintainers, but adds several seconds
-- 
1.7.9.5

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
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 17:03:40 +0200

[Message part 1 (text/plain, inline)]

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?

Regards,
  Stefano

[0001-build-support-and-require-Automake-NG.patch (text/x-diff, attachment)]

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.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11294 <at> debbugs.gnu.org
Subject: Re: bug#11294: [RFC] build: support and require Automake-NG
Date: Wed, 09 May 2012 01:08:21 +0200

Hi Jim, thanks for the feedback.

On 05/08/2012 09:57 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>>
>> 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)
>
Ugh, why do you do that?

> 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.
> 
OK.  Here it is:

  <http://github.com/slattarini/coreutils-am-ng>

If you can confirm that works correctly for you, feel free to close this
bug report.

Thanks,
  Stefano

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

From: Jim Meyering <jim <at> meyering.net>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 11294-close <at> debbugs.gnu.org
Subject: Re: bug#11294: [RFC] build: support and require Automake-NG
Date: Wed, 09 May 2012 13:57:12 +0200

Stefano Lattarini wrote:
> Hi Jim, thanks for the feedback.
> On 05/08/2012 09:57 PM, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>>>
>>> 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)
>>
> Ugh, why do you do that?

That update/push hook is to avoid accidental same-branch merges.
Eventually I might relax it to allow cross-branch merges, though
probably only with a small, fixed set of branch names.

>> 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.
>>
> OK.  Here it is:
>
>   <http://github.com/slattarini/coreutils-am-ng>
>
> If you can confirm that works correctly for you, feel free to close this
> bug report.

Thanks.  Confirmed and done.

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 11294-close <at> debbugs.gnu.org
Subject: Re: bug#11294: [RFC] build: support and require Automake-NG
Date: Wed, 09 May 2012 14:07:44 +0200

On 05/09/2012 01:57 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>> Hi Jim, thanks for the feedback.
>> On 05/08/2012 09:57 PM, Jim Meyering wrote:
>>> Stefano Lattarini wrote:
>>>>
>>>> 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)
>>>
>> Ugh, why do you do that?
> 
> That update/push hook is to avoid accidental same-branch merges.
>
Ah, like a "git pull master" issues with the local master having diverged from
the remote one.  Got it now, makes definite sense.

>> If you can confirm that works correctly for you, feel free to close this
>> bug report.
> 
> Thanks.  Confirmed and done.
>
Good :-)

Best regards,
  Stefano

Previous Next

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