[Automake-ng] [PATCH] [ng] begin: branching automake-ng, from testsuite-work branch

[Stefano Lattarini]

This is the starting point of an experimental non-hostile fork
of automake, whose generated makefiles will only target GNU
make rather than portable make.

* README: Update, and add references to and excerpts from the
threads and discussions that motivated this fork.
* AUTHORS: List myself as the person who started this fork.
---
 AUTHORS   |    3 ++
 ChangeLog |   10 ++++++
 README    |   98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 109 insertions(+), 2 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index e63f8b7..2690ca6 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -19,3 +19,6 @@ Alexandre Duret-Lutz
 Ralf Wildenhues
   Random breakage.
   Maintenance since 2006.
+
+Stefano Lattarini
+  Started the Automake-NG fork.
diff --git a/ChangeLog b/ChangeLog
index 2de1e05..052fe3c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
 2011-12-15  Stefano Lattarini  <address@hidden>
 
+       [ng] begin: branching automake-ng, from testsuite-work branch
+       This is the starting point of an experimental non-hostile fork
+       of automake, whose generated makefiles will only target GNU
+       make rather than portable make.
+       * README: Update, and add references to and excerpts from the
+       threads and discussions that motivated this fork.
+       * AUTHORS: List myself as the person who started this fork.
+
+2011-12-15  Stefano Lattarini  <address@hidden>
+
        tests: fix spurious failure in 'color2.test'
        * tests/color2.test: (expect-make): Add an "expect eof" directive,
        so that the collected output from the spawned make program will be
diff --git a/README b/README
index eb49e71..a9d477f 100644
--- a/README
+++ b/README
@@ -1,6 +1,100 @@
+============================ WARNING! =====================================
+==  This is *not* Automake, but rather "Automake-NG": an experimental,   ==
+==  non-hostile fork of automake; Automake-NG mostly differs from stock  ==
+==  Automake for the fact that its generated makefiles will only target  ==
+==  GNU make rather than portable make.                                  ==
+===========================================================================
+
+Reference to the thread kicking off this project:
+
+ "Could automake-generated Makefiles required GNU make?"
+ <http://lists.gnu.org/archive/html/automake/2011-11/msg00017.html>
+
+with partial consensus reached here:
+
+ <http://lists.gnu.org/archive/html/automake/2011-11/msg00088.htm>
+
+The discussion continued also in a thread on the gnu-prog-discuss list,
+which unfortunately is a private list dedicated to GNU maintainers, and
+thus for which no public archive is available.  The title of the thread
+was "Automire: a non-hostile forking of GNU automake", and it was started
+by me (Stefano Lattarini) on 2011-12-01.
+
+-*-*-
+
+The name "Automake-NG" for this automake variant has two reasons, which
+are motivated by two apparently incompatible (but in fact only orthogonal)
+concerns:
+
+  1. Paolo Bonzini pointed out that a backward-incompatible (even if only
+     partly so) "Automake 2" might propagate the past bad reputation of
+     the autotools w.r.t. backward-incompatibility.  So the new project
+     should be a fork of automake, with a name of its own.  I proposed
+     "Automire" as the name, to give credit to the Quagmire attempt,
+     while retaining the `am' namespace.  But then ...
+
+  2. Stefan Monnier noted (on the non-public gnu-prog-discuss list):
+
+     ``From where I stand, if you want the product to be successful,
+       you'll want its heritage to be very clear from the name.  To me
+       "automire" doesn't remind of "automake" at all.  To someone aware
+       of Quagmire, it may sound like "automatically mired in Quagmire's
+       problems".   I understand that if Automake is still live on, yours
+       can't just be "Automake 3.0", but it can be "automake-ng"''
+
+    to which I (Stefano Lattarini) replied:
+
+    ``You might be right about this, especially considering that the new
+      project is planned to have two phases, in the first one of which it
+      will remain very similar to automake in APIs and features (and,
+      sadly, limitations).  And `automake-ng' sounds like a good name
+      -- "ng" as in "New Generation", or more modestly, as in "Needs
+      GNUmake" ;-)''
+
+-*-*-
+
+From a private discussion with Karl Berry (slightly edited, and private
+as in "it hasn't taken place an any list, public or non-public"):
+
+  Karl Berry wrote:
+  > Regardless of how it is developed (multiple git repos or whatever,
+  > that's a completely independent question), I continue to believe that
+  > the best outcome would be an "automake-2" that targets GNU make and is
+  > "mostly" compatible, for whatever definition of "mostly" makes sense.
+  >
+  OK ... [SNIP] ... I mostly agree with you about this (but for the name
+  of the project, that is), at least as a first step.  Let me state my
+  plan in more precise terms (and sorry for not having done it before):
+
+   1. First, we start refactoring the automake codebase to transform
+      it into "Automake-NG": a mostly Automake-compatible software, with
+      only marginal or minor changes in APIs, that shares a lot of code
+      and design with Automake, but whose generated Makefiles require GNU
+      make.  See also point [3] at:
+        <http://lists.gnu.org/archive/html/automake/2011-01/msg00077.html>
+      Automake-NG will, where feasible, take advantage of GNU make features
+      to simplify its internals and implementation, but this will hardly
+      offer a better user experience for Makefile.am writers.  See also
+      sensible Ralf's observations at:
+        <http://lists.gnu.org/archive/html/automake/2011-01/msg00053.html>
+
+   2. If Automake-NG has been successful, we might proceed to develop
+      "Automire": a more agressive rewrite, with profound APIs, design
+      and code changes, in the hope of making automire easier to use and
+      to extend (lack of extensibility on part of the user is probably
+      one of the greatest shortcoming of the current automake).
+
+  And even if we fail to finally develop Automire, I believe that
+  Automake-NG will still be by itself a worth and useful step forward.
+
+  > Presumably it will have plenty of user-level benefits, too, and not
+  > just a cleaner implementation.
+
+===========================================================================
+
 This is Automake, a Makefile generator.  It was inspired by the 4.4BSD
-make and include files, but aims to be portable and to conform to the
-GNU Coding Standards for Makefile variables and targets.
+make and include files, but it only targets GNU make, and it aims to
+conform to the GNU Coding Standards for Makefile variables and targets.
 
 Automake is a Perl script.  The input files are called Makefile.am.
 The output files are called Makefile.in; they are intended for use
-- 
1.7.2.3