]> git.ipfire.org Git - thirdparty/automake.git/commitdiff
Merge branch 'master' into ng/master
authorStefano Lattarini <stefano.lattarini@gmail.com>
Thu, 16 Feb 2012 20:59:46 +0000 (21:59 +0100)
committerStefano Lattarini <stefano.lattarini@gmail.com>
Thu, 16 Feb 2012 20:59:46 +0000 (21:59 +0100)
* 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'.

1  2 
Makefile.am
README
syntax-checks.mk
tests/gen-testsuite-part

diff --cc Makefile.am
Simple merge
diff --cc README
index 3c46c77b53c5e4431b270853af9e9a3e5dc4da94,e955857742a8677fc82b6788aef35e8ad357d35c..08ce966aae9b28d872e055ee9ff1f6a138010c52
--- 1/README
--- 2/README
+++ b/README
 -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
Simple merge
Simple merge