[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FYI] New experimental branch `automake-ng'
[FYI] New experimental branch `automake-ng'
Thu, 15 Dec 2011 13:14:37 +0100
KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )
I've created a new branch named `automake-ng' to start experimenting
with the idea of an automake "heir" that could require GNU make in
its generated Makefile. References:
(plus a discussion on gnu-prog-discussion which unfortunately is
not publicly available).
The branch is an experimental one, and will possibly be renamed, rewinded
or tampered with in other ways, so beware. Also, it's quite low-priority
compared with the goal of releasing automake 1.12 in a not-so-distant
future (as more than two years have already passed since the previous
release), so don't expect a flurry of activity in the new branch. Still,
I'll try to make it proceed steadily and with continuance (albeit at a
somewhat glacial pace).
More details will be found in the updated `README' file in the new
branch, mostly condensing from the consensus and decisions reached
in the discussions referenced above.
Attached is the patch for the first commit in the new branch. Comments
and feedback are welcome.
From 0cff2c4eef5773744698eb32bd7a4cdec005c36e Mon Sep 17 00:00:00 2001
From: Stefano Lattarini <address@hidden>
Date: Thu, 15 Dec 2011 12:59:19 +0100
Subject: [PATCH] [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.
AUTHORS | 3 ++
ChangeLog | 10 ++++++
README | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index e63f8b7..2690ca6 100644
@@ -19,3 +19,6 @@ Alexandre Duret-Lutz
Maintenance since 2006.
+ Started the Automake-NG fork.
diff --git a/ChangeLog b/ChangeLog
index 4c17eb4..acef2e9 100644
@@ -1,3 +1,13 @@
+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-09 Jim Meyering <address@hidden>
Stefano Lattarini <address@hidden>
diff --git a/README b/README
index eb49e71..a9d477f 100644
@@ -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?"
+with partial consensus reached here:
+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)
+ 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  at:
+ 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:
+ 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
|[Prev in Thread]
||[Next in Thread]|
- [FYI] New experimental branch `automake-ng',
Stefano Lattarini <=