-This is Automake, a Makefile generator. It aims to be portable and
-to conform to the GNU Coding Standards for Makefile variables and
-targets.
+============================ 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 on any list, neither public nor 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 it only targets GNU make, and it aims to
++This is Automake, a Makefile generator. It targets GNU make, and aims to
+conform to the GNU Coding Standards for Makefile variables and targets.
+ See the INSTALL file for detailed information about how to configure
+ and install Automake.
+
Automake is a Perl script. The input files are called Makefile.am.
The output files are called Makefile.in; they are intended for use
with Autoconf. Automake requires certain things to be done in your