The first version of the automake script looks as follows.
#!/bin/sh
status=0
for makefile
do
if test ! -f ${makefile}.am; then
echo "automake: ${makefile}.am: No such honkin' file"
status=1
continue
fi
exec 4> ${makefile}.in
done
From this you can already see that Automake will be about reading *.am file and producing *.in files. You cannot see anything else, but if you also know that David is the one who created Autoconf two years before you can guess the rest.
Several commits follow, and by the end of the day Automake is reported to work for GNU fileutils and GNU m4.
The modus operandi is the one that is still used today: variable assignments in Makefile.am files trigger injections of precanned Makefile fragments into the generated Makefile.in. The use of Makefile fragments was inspired by the 4.4BSD make and include files, however Automake aims to be portable and to conform to the GNU standards for Makefile variables and targets.
At this point, the most recent release of Autoconf is version 1.11,
and David is preparing to release Autoconf 2.0 in late October. As a
matter of fact, he will barely touch Automake after September.
I wrote it keeping in mind the possibility of it becoming an Autoconf macro, so it would run at configure-time. That would slow configuration down a bit, but allow users to modify the Makefile.am without needing to fetch the AutoMake package. And, the Makefile.in files wouldn't need to be distributed. But all of AutoMake would. So I might reimplement AutoMake in Perl, m4, or some other more appropriate language.
Automake is described as “an experimental Makefile generator”. There is no documentation. Adventurous users are referred to the examples and patches needed to use Automake with GNU m4 1.3, fileutils 3.9, time 1.6, and development versions of find and indent.
These examples seem to have been lost. However at the time of writing
(10 years later in September, 2004) the FSF still distributes a
package that uses this version of Automake: check out GNU termutils
2.0.
Tom didn't talk to djm about it until later, just to make sure he didn't mind if he made a release. He did a bunch of early releases to the Gnits folks.
Gnits was (and still is) totally informal, just a few GNU friends who
François Pinard knew, who were all interested in making a common
infrastructure for GNU projects, and shared a similar outlook on how
to do it. So they were able to make some progress. It came along
with Autoconf and extensions thereof, and then Automake from David and
Tom (who were both gnitsians). One of their ideas was to write a
document paralleling the GNU standards, that was more strict in some
ways and more detailed. They never finished the GNITS standards, but
the ideas mostly made their way into Automake.
At this time aclocal and AM_INIT_AUTOMAKE did not
exist, so many things had to be done by hand. For instance, here is
what a configure.in (this is the former name of the
configure.ac we use today) must contain in order to use
Automake 0.20:
PACKAGE=cpio
VERSION=2.3.911
AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE")
AC_DEFINE_UNQUOTED(VERSION, "$VERSION")
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_ARG_PROGRAM
AC_PROG_INSTALL
(Today all of the above is achieved by AC_INIT and
AM_INIT_AUTOMAKE.)
Here is how programs are specified in Makefile.am:
PROGRAMS = hello
hello_SOURCES = hello.c
This looks pretty much like what we do today, except the
PROGRAMS variable has no directory prefix specifying where
hello should be installed: all programs are installed in
‘$(bindir)’. LIBPROGRAMS can be used to specify programs
that must be built but not installed (it is called
noinst_PROGRAMS nowadays).
Programs can be built conditionally using AC_SUBSTitutions:
PROGRAMS = @progs@
AM_PROGRAMS = foo bar baz
(AM_PROGRAMS has since then been renamed to
EXTRA_PROGRAMS.)
Similarly scripts, static libraries, and data can be built and installed
using the LIBRARIES, SCRIPTS, and DATA variables.
However LIBRARIES were treated a bit specially in that Automake
did automatically supply the lib and .a prefixes.
Therefore to build libcpio.a, one had to write
LIBRARIES = cpio
cpio_SOURCES = ...
Extra files to distribute must be listed in DIST_OTHER (the
ancestor of EXTRA_DIST). Also extra directories that are to be
distributed should appear in DIST_SUBDIRS, but the manual
describes this as a temporary ugly hack (today extra directories should
also be listed in EXTRA_DIST, and DIST_SUBDIRS is used
for another purpose, see Conditional Subdirectories).
If you never used Perl 4, imagine Perl 5 without objects, without
‘my’ variables (only dynamically scoped ‘local’ variables),
without function prototypes, with function calls that needs to be
prefixed with ‘&’, etc. Traces of this old style can still be
found in today's automake.
bin_PROGRAMS instead of PROGRAMS,
noinst_LIBRARIES instead of LIBLIBRARIES, etc. (However
EXTRA_PROGRAMS does not exist yet, AM_PROGRAMS is still
in use; and TEXINFOS and MANS still have no directory
prefixes.) Adding support for prefixes like that was one of the major
ideas in automake; it has lasted pretty well.
AutoMake is renamed to Automake (Tom seems to recall it was François Pinard's doing).
0.25 fixes a Perl 4 portability bug.
Gordon Matzigkeit and Jim Meyering are two other early contributors that have been sending fixes.
0.27 fixes yet another Perl 4 portability bug.
LIBOBJS
support. This is an important step because until this version
Automake only knew about the Makefile.ams it processed.
configure.in was Autoconf's world and the link between Autoconf
and Automake had to be done by the Makefile.am author. For
instance, if config.h was generated by configure, it was the
package maintainer's responsibility to define the CONFIG_HEADER
variable in each Makefile.am.
Succeeding releases will rely more and more on scanning configure.in to better automate the Autoconf integration.
0.28 also introduces the AUTOMAKE_OPTIONS variable and the
--gnu and --gnits options, the latter being stricter.
CONFIG_HEADER is gone,
and rebuild rules for configure-generated file are
automatically output.
TEXINFOS and MANS converted to the uniform naming
scheme.
EXTRA_PROGRAMS finally replaces AM_PROGRAMS.
All the third-party Autoconf macros, written mostly by François
Pinard (and later Jim Meyering), are distributed in Automake's
hand-written aclocal.m4 file. Package maintainers are expected
to extract the necessary macros from this file. (In previous versions
you had to copy and paste them from the manual...)
check-local rule. Upon
Ulrich Drepper's suggestion, 0.31 makes it an Automake rule output
whenever the TESTS variable is defined.
DIST_OTHER is renamed to EXTRA_DIST, and the check_
prefix is introduced. The syntax is now the same as today.
-hook targets are introduced; an idea from Dieter Baron.
*.info files, which were output in the build directory are
now built in the source directory, because they are distributed. It
seems these files like to move back and forth as that will happen
again in future versions.
Although they were very basic at this point, these are probably among the top features for Automake today.
Jim Meyering also provides the infamous jm_MAINTAINER_MODE, since
then renamed to AM_MAINTAINER_MODE and abandoned by its author
(see maintainer-mode).
From now on and until version 1.4, new releases will occur at a rate
of about one a year. 1.1 did not exist, actually 1.1b to 1.1p have
been the name of beta releases for 1.2. This is the first time
Automake uses suffix letters to designate beta releases, a habit that
lasts.
I've created the "automake" mailing list. It is
"[email protected]". Administrivia, as always, to
[email protected].
The charter of this list is discussion of automake, autoconf, and
other configuration/portability tools (e.g., libtool). It is expected
that discussion will range from pleas for help all the way up to
patches.
This list is archived on the FSF machines. Offhand I don't know if
you can get the archive without an account there.
This list is open to anybody who wants to join. Tell all your
friends!
-- Tom Tromey
Before that people were discussing Automake privately, on the Gnits
mailing list (which is not public either), and less frequently on
gnu.misc.discuss.
gnu.ai.mit.edu is now gnu.org, in case you never
noticed. The archives of the early years of the
[email protected] list have been lost, so today it is almost
impossible to find traces of discussions that occurred before 1999.
This has been annoying more than once, as such discussions can be
useful to understand the rationale behind a piece of uncommented code
that was introduced back then.
The 1.2 release contains 20 macros, including the
AM_INIT_AUTOMAKE macro that simplifies the creation of
configure.in.
Libtool is fully supported using *_LTLIBRARIES.
The missing script is introduced by François Pinard; it is meant
to be a better solution than AM_MAINTAINER_MODE
(see maintainer-mode).
Conditionals support was implemented by Ian Lance Taylor. At the time, Tom and Ian were working on an internal project at Cygnus. They were using ILU, which is pretty similar to CORBA. They wanted to integrate ILU into their build, which was all configure-based, and Ian thought that adding conditionals to automake was simpler than doing all the work in configure (which was the standard at the time). So this was actually funded by Cygnus.
This very useful but tricky feature will take a lot of time to stabilize. (At the time this text is written, there are still primaries that have not been updated to support conditional definitions in Automake 1.9.)
The automake script has almost doubled: 6089 lines of Perl,
plus 1294 lines of Makefile fragments.
Perl 5.004_04 is out, but fixes to support Perl 4 are still
regularly submitted whenever Automake breaks it.
sourceware.cygnus.com is on-line.sourceware.cygnus.comsourceware.cygnus.com announces it hosts Automake:sourceware.cygnus.com. It has a
publicly accessible CVS repository. This CVS repository is a copy of
the one Tom was using on his machine, which in turn is based on
a copy of the CVS repository of David MacKenzie. This is why we still
have to full source history. (Automake was on Sourceware until 2007-10-29,
when it moved to a git repository on savannah.gnu.org,
but the Sourceware host had been renamed to sources.redhat.com.)
The oldest file in the administrative directory of the CVS repository that was created on Sourceware is dated 1998-09-19, while the announcement that automake and autoconf had joined sourceware was made on 1998-10-26. They were among the first projects to be hosted there.
The heedful reader will have noticed Automake was exactly 4 years old
on 1998-09-19.
include
statement. Also, ‘+=’ assignments are introduced, but it is
still quite easy to fool Automake when mixing this with conditionals.
These two releases, Automake 1.4 and Autoconf 2.13 make a duo that will be used together for years.
automake is 7228 lines, plus 1591 lines of Makefile
fragment, 20 macros (some 1.3 macros were finally contributed back to
Autoconf), 197 test cases, and 51 pages of documentation.
user-dep-branch is created on the CVS repository.See Dependency Tracking Evolution, for more details about the
evolution of automatic dependency tracking in Automake.
user-dep-branch is merged into the main trunk.I think the next release should be called "3.0".
Let's face it: you've basically rewritten autoconf.
Every weekend there are 30 new patches.
I don't see how we could call this "2.15" with a straight face.
– Tom Tromey on [email protected]
Actually Akim works like a submarine: he will pile up patches while he
works off-line during the weekend, and flush them in batch when he
resurfaces on Monday.
Aiieeee! I was dreading the day that the Demaillator turned his sights on automake... and now it has arrived! – Tom Tromey
It's only the beginning: in two months he will send 192 patches. Then he would slow down so Tom can catch up and review all this. Initially Tom actually read all these patches, then he probably trustingly answered OK to most of them, and finally gave up and let Akim apply whatever he wanted. There was no way to keep up with that patch rate.
Anyway the patch below won't apply since it predates Akim's sourcequake; I have yet to figure where the relevant passage has been moved :) – Alexandre Duret-Lutz
All these patches were sent to and discussed on [email protected], so subscribed users were literally drowning in technical mails. Eventually, the [email protected] mailing list was created in May.
Year after year, Automake had drifted away from its initial design: construct Makefile.in by assembling various Makefile fragments. In 1.4, lots of Makefile rules are being emitted at various places in the automake script itself; this does not help ensuring a consistent treatment of these rules (for instance making sure that user-defined rules override Automake's own rules). One of Akim's goal was moving all these hard-coded rules to separate Makefile fragments, so the logic could be centralized in a Makefile fragment processor.
Another significant contribution of Akim is the interface with the
“trace” feature of Autoconf. The way to scan configure.in at
this time was to read the file and grep the various macro of interest
to Automake. Doing so could break in many unexpected ways; automake
could miss some definition (for instance ‘AC_SUBST([$1], [$2])’
where the arguments are known only when M4 is run), or conversely it
could detect some macro that was not expanded (because it is called
conditionally). In the CVS version of Autoconf, Akim had implemented
the --trace option, which provides accurate information about
where macros are actually called and with what arguments. Akim will
equip Automake with a second configure.in scanner that uses
this --trace interface. Since it was not sensible to drop the
Autoconf 2.13 compatibility yet, this experimental scanner was only
used when an environment variable was set, the traditional
grep-scanner being still the default.
The main purpose of this release is to have a stable automake which is compatible with the latest stable libtool.
The release also contains obvious fixes for bugs in Automake 1.4,
some of which were reported almost monthly.
AC_OUTPUTing files.
dist_, nodist_, and nobase_
prefixes.
1.5 did break several packages that worked with 1.4. Enough so that Linux distributions could not easily install the new Automake version without breaking many of the packages for which they had to run automake.
Some of these breakages were effectively bugs that would eventually be fixed in the next release. However, a lot of damage was caused by some changes made deliberately to render Automake stricter on some setup we did consider bogus. For instance, ‘make distcheck’ was improved to check that ‘make uninstall’ did remove all the files ‘make install’ installed, that ‘make distclean’ did not omit some file, and that a VPATH build would work even if the source directory was read-only. Similarly, Automake now rejects multiple definitions of the same variable (because that would mix very badly with conditionals), and ‘+=’ assignments with no previous definition. Because these changes all occurred suddenly after 1.4 had been established for more than two years, it hurt users.
To make matter worse, meanwhile Autoconf (now at version 2.52) was
facing similar troubles, for similar reasons.
The idea was to call this version automake-1.6, call all its bug-fix versions identically, and switch to automake-1.7 for the next release that adds new features or changes some rules. This scheme implies maintaining a bug-fix branch in addition to the development trunk, which means more work from the maintainer, but providing regular bug-fix releases proved to be really worthwhile.
Like 1.5, 1.6 also introduced a bunch of incompatibilities, intentional or not. Perhaps the more annoying was the dependence on the newly released Autoconf 2.53. Autoconf seemed to have stabilized enough since its explosive 2.50 release and included changes required to fix some bugs in Automake. In order to upgrade to Automake 1.6, people now had to upgrade Autoconf too; for some packages it was no picnic.
While versioned installation helped people to upgrade, it also
unfortunately allowed people not to upgrade. At the time of writing,
some Linux distributions are shipping packages for Automake 1.4, 1.5,
1.6, 1.7, 1.8, and 1.9. Most of these still install 1.4 by default.
Some distribution also call 1.4 the “stable” version, and present
“1.9” as the development version; this does not really makes sense
since 1.9 is way more solid than 1.4. All this does not help the
newcomer.
Alexandre has been using Automake since 2000, and started to
contribute mostly on Akim's incitement (Akim and Alexandre have been
working in the same room from 1999 to 2002). In 2001 and 2002 he had
a lot of free time to enjoy hacking Automake.
Tom Tromey backported the versioned installation mechanism on the 1.4
branch, so that Automake 1.6.x and Automake 1.4-p6 could be installed
side by side. Another request from the GNOME folks.
Marshall, one of the characters, is working on a computer virus that he
has to modify before it gets into the wrong hands or something like
that. The screenshots you see do not show any program code, they show
a Makefile.in generated by automake...
aclocal now uses m4_include in the produced
aclocal.m4 when the included macros are already distributed
with the package (an idiom used in many packages), which reduces code
duplication. Many people liked that, but in fact this change was
really introduced to fix a bug in rebuild rules: Makefile.in
must be rebuilt whenever a dependency of configure changes, but
all the m4 files included in aclocal.m4 where unknown
from automake. Now automake can just trace the
m4_includes to discover the dependencies.
aclocal also starts using the --trace Autoconf option
in order to discover used macros more accurately. This will turn out
to be very tricky (later releases will improve this) as people had
devised many ways to cope with the limitation of previous
aclocal versions, notably using handwritten
m4_includes: aclocal must make sure not to redefine a
rule that is already included by such statement.
Automake also has seen its guts rewritten. Although this rewriting took a lot of efforts, it is only apparent to the users in that some constructions previously disallowed by the implementation now work nicely. Conditionals, Locations, Variable and Rule definitions, Options: these items on which Automake works have been rewritten as separate Perl modules, and documented.
Aside from this it contains mainly minor changes and bug-fixes.
savannah.gnu.org