summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
Diffstat (limited to 'README')
-rw-r--r--README137
1 files changed, 109 insertions, 28 deletions
diff --git a/README b/README
index fdf25fa0c..058ed139a 100644
--- a/README
+++ b/README
@@ -1,16 +1,111 @@
-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* mainstream Automake, but rather "Automake-NG": an ==
+== experimental, non-hostile fork of it. Automake-NG mostly differs ==
+== from mainstream Automake in that its generated makefiles 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 aggressive 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-NG, 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.
+and install Automake-NG.
-Automake is a Perl script. The input files are called Makefile.am.
+Automake-NG 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
+with Autoconf. Automake-NG requires certain things to be done in your
configure.ac.
-Automake comes with extensive documentation; please refer to it for
+Automake-NG comes with extensive documentation; please refer to it for
more details about its purpose, features, and usage patterns.
This package also includes the "aclocal" program, whose purpose is
@@ -18,30 +113,16 @@ to generate an 'aclocal.m4' based on the contents of 'configure.ac'.
It is useful as an extensible, maintainable mechanism for augmenting
autoconf. It is intended that other package authors will write m4
macros which can be automatically used by aclocal. The documentation
-for aclocal is currently found in the Automake manual.
+for aclocal is currently found in the Automake-NG manual.
-Automake has a test suite. Use "make check" to run it. For more
+Automake-NG has a test suite. Use "make check" to run it. For more
information, see the file t/README.
-Automake has a page on the web. See:
-
- http://www.gnu.org/software/automake/
-
-Automake also has three mailing lists:
-
- * automake@gnu.org
- For general discussions of Automake and its interactions with other
- configuration/portability tools like Autoconf or Libtool.
-
- * bug-automake@gnu.org
- Where to send bug reports and feature requests.
-
- * automake-patches@gnu.org
- Where to send patches, and discuss the automake development process
- and the design of new features.
-
-To obtain more information about these list, or to subscribe to them,
-refer to <http://www.gnu.org/software/automake/#mailinglists>
+Automake-NG still doesn't have a page on the web. But it has one
+mailing list, <automake-ng@gnu.org>, that can be used for general
+discussions and to send bug reports, feature requests, and patches.
+To obtain more information about this list, or to subscribe to it,
+refer to <http://lists.gnu.org/mailman/listinfo/automake-ng/>
New releases are announced to autotools-announce@gnu.org. If you want to
be informed, subscribe to that list by following the instructions at