summaryrefslogtreecommitdiff
path: root/README
blob: 058ed139a928b45528bf2fb3a6bb865bf803b404 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
============================ 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-NG.

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-NG requires certain things to be done in your
configure.ac.

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
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-NG manual.

Automake-NG has a test suite.  Use "make check" to run it.  For more
information, see the file t/README.

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
<http://lists.gnu.org/mailman/listinfo/autotools-announce>.

For any copyright year range specified as YYYY-ZZZZ in this package,
that the range specifies every single year in that closed interval.

-----

Copyright (C) 1994-2012 Free Software Foundation, Inc.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.