From: Stefano Lattarini Date: Thu, 16 Feb 2012 20:59:46 +0000 (+0100) Subject: Merge branch 'master' into ng/master X-Git-Tag: ng-0.5a~6 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9fc8baccf523a3877a84c065c6c3f2599e0d2147;p=thirdparty%2Fautomake.git Merge branch 'master' into ng/master * master: readme: update and renew depcomp tests: fix up today's botched commit build: clearer diagnostic if "make" is invoked before "./configure" depcomp tests: put TAP plan in generated tests update-copyright: don't touch COPYING and INSTALL maintcheck: whitelist some false positives + Extra diffs: * syntax-checks.mk: Throw away changes to the obsolete check 'sc_tests_overriding_macros_on_cmdline'. --- 9fc8baccf523a3877a84c065c6c3f2599e0d2147 diff --cc README index 3c46c77b5,e95585774..08ce966aa --- a/README +++ b/README @@@ -1,101 -1,10 +1,103 @@@ -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?" + + +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) +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: + + 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 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