/aclocal
/automake
/doc/amhello-*.tar.gz
-/doc/automake.info
-/doc/automake.info-[0-9]
+/doc/automake*.info
+/doc/automake*.info-[0-9]
/doc/automake*.1
/doc/aclocal*.1
/doc/stamp-vti
/doc/version.texi
-/doc/automake.ac
-/doc/automake.aux
-/doc/automake.cm
-/doc/automake.cp
-/doc/automake.cps
-/doc/automake.dvi
-/doc/automake.fn
-/doc/automake.fns
-/doc/automake.html
-/doc/automake.ky
-/doc/automake.log
-/doc/automake.op
-/doc/automake.pdf
-/doc/automake.pg
-/doc/automake.ps
-/doc/automake.toc
-/doc/automake.tp
-/doc/automake.tr
-/doc/automake.vr
-/doc/automake.vrs
+/doc/automake*.ac
+/doc/automake*.aux
+/doc/automake*.cm
+/doc/automake*.cp
+/doc/automake*.cps
+/doc/automake*.dvi
+/doc/automake*.fn
+/doc/automake*.fns
+/doc/automake*.html
+/doc/automake*.ky
+/doc/automake*.log
+/doc/automake*.op
+/doc/automake*.pdf
+/doc/automake*.pg
+/doc/automake*.ps
+/doc/automake*.toc
+/doc/automake*.tp
+/doc/automake*.tr
+/doc/automake*.vr
+/doc/automake*.vrs
/doc/amhello/Makefile.in
/doc/amhello/aclocal.m4
/doc/amhello/config.h.in
* Run this:
./bootstrap && ./configure && make && make check && make distcheck
-* Run `make release-stats' if release statistics in doc/automake.texi
- have not been updated yet.
-
* Run `make git-release'.
This will run "make dist" to create the tarballs, commit the last
changes to NEWS, configure.ac and m4/amversion.m4, tag the repository,
echo "See Fetchdir/update.patch for a log of the changes."; \
exit $$stat
.PHONY: fetch
-
-## Generate release statistics, for the table in automake.texi.
-## This has to be run in an up to date build tree, but there must
-## be no temp files nor unused other files lying around!
-release-stats: ps
- $(AM_V_GEN): && \
- am=`wc -l < automake` && \
- acl=`wc -l < aclocal` && \
- pmfiles="lib/Automake/*.pm" && \
- if test . != '$(srcdir)'; then pmfiles="$$pmfiles $(srcdir)/lib/Automake/*.pm"; \
- else :; fi && \
- pm=`cat $$pmfiles | wc -l` && \
- dot_am_files=`ls -1 $(srcdir)/lib/am/*.am | grep -v Makefile.am` && \
- amf=`echo "$$dot_am_files" | wc -l` && \
- aml=`cat $$dot_am_files | wc -l` && \
- m4f=`ls -1 $(srcdir)/m4/*.m4 | wc -l` && \
- m4l=`cat $(srcdir)/m4/*.m4 | wc -l` && \
- doc_text=`$(am__cd) doc && LC_ALL=C pstops 0 automake.ps unused.ps 2>&1` && \
- echo "$$doc_text" && \
- rm -f doc/unused.ps && \
- doc=`echo "$$doc_text" | sed -n 's/.*Wrote \([1-9][0-9]*\) pages.*/\1/p'` && \
- tests="tests/*.test"; \
- if test . != '$(srcdir)'; then tests="$$tests $(srcdir)/tests/*.test"; \
- else :; fi && \
- t=`ls -1 $$tests | wc -l` && \
- tgen=`grep 'GENERATED AUTOMATICALLY' $$tests | wc -l` && \
- today=`date +%Y-%m-%d` && \
- echo "add this to the table in doc/automake.texi after verification:" && \
- printf '@item %s @tab %-6s @tab %4d @tab %4d @tab %4d @tab %4d %-4s @tab %4d %-4s @tab %3d @tab %d %-4s\n' \
- $$today $(VERSION) $$am $$acl $$pm $$aml "($$amf)" $$m4l "($$m4f)" $$doc $$t "($$tgen)"
-.PHONY: release-stats
- The deprecated options `--output-dir', `--Werror' and `--Wno-error'
have been removed.
+ - The chapter on the history of Automake has been moved out of the
+ reference manual, into a new dedicated Texinfo file.
+
* New targets:
- New `cscope' target to build a cscope database for the source tree.
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-info_TEXINFOS = automake.texi
+info_TEXINFOS = automake.texi automake-history.texi
automake_TEXINFOS = fdl.texi
+history_TEXINFOS = fdl.texi
dist_man1_MANS = \
$(srcdir)/aclocal.1 \
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@c %**start of header
+@setfilename automake-history.info
+@settitle automake-history
+@setchapternewpage on
+@c %**end of header
+
+@copying
+
+This manual describes (part of) the history of GNU Automake, a program
+that creates GNU standards-compliant Makefiles from template files.
+
+Copyright @copyright{} 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free Software
+Foundation, Inc.
+
+@quotation
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License,
+Version 1.3 or any later version published by the Free Software
+Foundation; with no Invariant Sections, with no Front-Cover texts,
+and with no Back-Cover Texts. A copy of the license is included in the
+section entitled ``GNU Free Documentation License.''
+
+@end quotation
+@end copying
+
+@titlepage
+@title Brief History of Automake
+@author David MacKenzie
+@author Tom Tromey
+@author Alexandre Duret-Lutz
+@page
+@vskip 0pt plus 1filll
+@insertcopying
+@end titlepage
+
+@contents
+
+@ifnottex
+@node Top
+@comment node-name, next, previous, up
+@top Brief History of Automake
+
+@insertcopying
+
+@menu
+* Timeline:: The Automake story.
+* Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking
+* Releases:: Release statistics
+* Copying This Manual:: How to make copies of this manual
+
+@detailmenu
+ --- The Detailed Node Listing ---
+
+Evolution of Automatic Dependency Tracking
+
+* First Take on Dependencies:: Precomputed dependency tracking
+* Dependencies As Side Effects:: Update at developer compile time
+* Dependencies for the User:: Update at user compile time
+* Techniques for Dependencies:: Alternative approaches
+
+Techniques for Computing Dependencies
+
+* Recommendations for Tool Writers::
+* Future Directions for Dependencies::
+
+Copying This Manual
+
+* GNU Free Documentation License:: License for copying this manual
+
+@end detailmenu
+@end menu
+
+@end ifnottex
+
+@node Timeline
+@chapter Timeline
+
+@table @asis
+@item 1994-09-19 First CVS commit.
+
+If we can trust the CVS repository, David J.@tie{}MacKenzie (djm) started
+working on Automake (or AutoMake, as it was spelt then) this Monday.
+
+The first version of the @command{automake} script looks as follows.
+
+@example
+#!/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
+@end example
+
+From this you can already see that Automake will be about reading
+@file{*.am} file and producing @file{*.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 @file{Makefile.am} files trigger injections of
+precanned @file{Makefile} fragments into the generated
+@file{Makefile.in}. The use of @file{Makefile} fragments was inspired
+by the 4.4BSD @command{make} and include files, however Automake aims
+to be portable and to conform to the GNU standards for @file{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.
+
+@item 1994-11-05 David MacKenzie's last commit.
+
+At this point Automake is a 200 line portable shell script, plus 332
+lines of @file{Makefile} fragments. In the @file{README}, David
+states his ambivalence between ``portable shell'' and ``more
+appropriate language'':
+
+@quotation
+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.
+@end quotation
+
+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.
+
+@item 1995-11-12 Tom Tromey's first commit.
+
+After one year of inactivity, Tom Tromey takes over the package.
+Tom was working on GNU cpio back then, and doing this just for fun,
+having trouble finding a project to contribute to. So while hacking
+he wanted to bring the @file{Makefile.in} up to GNU standards. This
+was hard, and one day he saw Automake on @url{ftp://alpha.gnu.org/},
+grabbed it and tried it out.
+
+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@,cois 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.
+
+@item 1995-11-23 Automake 0.20
+
+Besides introducing automatic dependency tracking (@pxref{Dependency
+Tracking Evolution}), this version also supplies a 9-page manual.
+
+At this time @command{aclocal} and @code{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
+@file{configure.ac} we use today) must contain in order to use
+Automake 0.20:
+
+@example
+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
+@end example
+
+(Today all of the above is achieved by @code{AC_INIT} and
+@code{AM_INIT_AUTOMAKE}.)
+
+Here is how programs are specified in @file{Makefile.am}:
+
+@example
+PROGRAMS = hello
+hello_SOURCES = hello.c
+@end example
+
+This looks pretty much like what we do today, except the
+@code{PROGRAMS} variable has no directory prefix specifying where
+@file{hello} should be installed: all programs are installed in
+@samp{$(bindir)}. @code{LIBPROGRAMS} can be used to specify programs
+that must be built but not installed (it is called
+@code{noinst_PROGRAMS} nowadays).
+
+Programs can be built conditionally using @code{AC_SUBST}itutions:
+
+@example
+PROGRAMS = @@progs@@
+AM_PROGRAMS = foo bar baz
+@end example
+
+(@code{AM_PROGRAMS} has since then been renamed to
+@code{EXTRA_PROGRAMS}.)
+
+Similarly scripts, static libraries, and data can be built and installed
+using the @code{LIBRARIES}, @code{SCRIPTS}, and @code{DATA} variables.
+However @code{LIBRARIES} were treated a bit specially in that Automake
+did automatically supply the @file{lib} and @file{.a} prefixes.
+Therefore to build @file{libcpio.a}, one had to write
+
+@example
+LIBRARIES = cpio
+cpio_SOURCES = ...
+@end example
+
+Extra files to distribute must be listed in @code{DIST_OTHER} (the
+ancestor of @code{EXTRA_DIST}). Also extra directories that are to be
+distributed should appear in @code{DIST_SUBDIRS}, but the manual
+describes this as a temporary ugly hack (today extra directories should
+also be listed in @code{EXTRA_DIST}, and @code{DIST_SUBDIRS} is used
+for another purpose, @pxref{Conditional Subdirectories, , Conditional
+Subdirectories, automake, GNU Automake}).
+
+@item 1995-11-26 Automake 0.21
+
+In less time than it takes to cook a frozen pizza, Tom rewrites
+Automake using Perl. At this time Perl 5 is only one year old, and
+Perl 4.036 is in use at many sites. Supporting several Perl versions
+has been a source of problems through the whole history of Automake.
+
+If you never used Perl 4, imagine Perl 5 without objects, without
+@samp{my} variables (only dynamically scoped @samp{local} variables),
+without function prototypes, with function calls that needs to be
+prefixed with @samp{&}, etc. Traces of this old style can still be
+found in today's @command{automake}.
+
+@item 1995-11-28 Automake 0.22
+@itemx 1995-11-29 Automake 0.23
+
+Bug fixes.
+
+@item 1995-12-08 Automake 0.24
+@itemx 1995-12-10 Automake 0.25
+
+Releases are raining. 0.24 introduces the uniform naming scheme we
+use today, i.e., @code{bin_PROGRAMS} instead of @code{PROGRAMS},
+@code{noinst_LIBRARIES} instead of @code{LIBLIBRARIES}, etc. (However
+@code{EXTRA_PROGRAMS} does not exist yet, @code{AM_PROGRAMS} is still
+in use; and @code{TEXINFOS} and @code{MANS} still have no directory
+prefixes.) Adding support for prefixes like that was one of the major
+ideas in @command{automake}; it has lasted pretty well.
+
+AutoMake is renamed to Automake (Tom seems to recall it was Fran@,cois
+Pinard's doing).
+
+0.25 fixes a Perl 4 portability bug.
+
+@item 1995-12-18 Jim Meyering starts using Automake in GNU Textutils.
+@item 1995-12-31 Fran@,cois Pinard starts using Automake in GNU tar.
+
+@item 1996-01-03 Automake 0.26
+@itemx 1996-01-03 Automake 0.27
+
+Of the many changes and suggestions sent by Fran@,cois Pinard and
+included in 0.26, perhaps the most important is the advice that to
+ease customization a user rule or variable definition should always
+override an Automake rule or definition.
+
+Gordon Matzigkeit and Jim Meyering are two other early contributors
+that have been sending fixes.
+
+0.27 fixes yet another Perl 4 portability bug.
+
+@item 1996-01-13 Automake 0.28
+
+Automake starts scanning @file{configure.in} for @code{LIBOBJS}
+support. This is an important step because until this version
+Automake only knew about the @file{Makefile.am}s it processed.
+@file{configure.in} was Autoconf's world and the link between Autoconf
+and Automake had to be done by the @file{Makefile.am} author. For
+instance, if @file{config.h} was generated by @file{configure}, it was the
+package maintainer's responsibility to define the @code{CONFIG_HEADER}
+variable in each @file{Makefile.am}.
+
+Succeeding releases will rely more and more on scanning
+@file{configure.in} to better automate the Autoconf integration.
+
+0.28 also introduces the @code{AUTOMAKE_OPTIONS} variable and the
+@option{--gnu} and @option{--gnits} options, the latter being stricter.
+
+@item 1996-02-07 Automake 0.29
+
+Thanks to @file{configure.in} scanning, @code{CONFIG_HEADER} is gone,
+and rebuild rules for @file{configure}-generated file are
+automatically output.
+
+@code{TEXINFOS} and @code{MANS} converted to the uniform naming
+scheme.
+
+@item 1996-02-24 Automake 0.30
+
+The test suite is born. It contains 9 tests. From now on test cases
+will be added pretty regularly (@pxref{Releases}), and this proved to
+be really helpful later on.
+
+@code{EXTRA_PROGRAMS} finally replaces @code{AM_PROGRAMS}.
+
+All the third-party Autoconf macros, written mostly by Fran@,cois
+Pinard (and later Jim Meyering), are distributed in Automake's
+hand-written @file{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...)
+
+@item 1996-03-11 Automake 0.31
+
+The test suite in 0.30 was run via a long @code{check-local} rule. Upon
+Ulrich Drepper's suggestion, 0.31 makes it an Automake rule output
+whenever the @code{TESTS} variable is defined.
+
+@code{DIST_OTHER} is renamed to @code{EXTRA_DIST}, and the @code{check_}
+prefix is introduced. The syntax is now the same as today.
+
+@item 1996-03-15 Gordon Matzigkeit starts writing libtool.
+
+@item 1996-04-27 Automake 0.32
+
+@code{-hook} targets are introduced; an idea from Dieter Baron.
+
+@file{*.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.
+
+@item 1996-05-18 Automake 0.33
+
+Gord Matzigkeit's main two contributions:
+
+@itemize
+@item very preliminary libtool support
+@item the distcheck rule
+@end itemize
+
+Although they were very basic at this point, these are probably
+among the top features for Automake today.
+
+Jim Meyering also provides the infamous @code{jm_MAINTAINER_MODE}, since
+then renamed to @code{AM_MAINTAINER_MODE} and abandoned by its author
+(@pxref{maintainer-mode, , maintainer-mode, automake, GNU Automake}).
+
+@item 1996-05-28 Automake 1.0
+
+After only six months of heavy development, the @command{automake} script is
+3134 lines long, plus 973 lines of @file{Makefile} fragments. The
+package has 30 pages of documentation, and 38 test cases.
+@file{aclocal.m4} contains 4 macros.
+
+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.
+
+@item 1996-10-10 Kevin Dalley packages Automake 1.0 for Debian GNU/Linux.
+
+@item 1996-11-26 David J.@tie{}MacKenzie releases Autoconf 2.12.
+
+Between June and October, the Autoconf development is almost stalled.
+Roland McGrath has been working at the beginning of the year. David
+comes back in November to release 2.12, but he won't touch Autoconf
+anymore after this year, and Autoconf then really stagnates. The
+desolate Autoconf @file{ChangeLog} for 1997 lists only 7 commits.
+
+@item 1997-02-28 @email{automake@@gnu.ai.mit.edu} list alive
+
+The mailing list is announced as follows:
+@smallexample
+I've created the "automake" mailing list. It is
+"automake@@gnu.ai.mit.edu". Administrivia, as always, to
+automake-request@@gnu.ai.mit.edu.
+
+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
+@end smallexample
+
+Before that people were discussing Automake privately, on the Gnits
+mailing list (which is not public either), and less frequently on
+@code{gnu.misc.discuss}.
+
+@code{gnu.ai.mit.edu} is now @code{gnu.org}, in case you never
+noticed. The archives of the early years of the
+@code{automake@@gnu.org} 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.
+
+@item 1997-06-22 Automake 1.2
+
+Automake developments continues, and more and more new Autoconf macros
+are required. Distributing them in @file{aclocal.m4} and requiring
+people to browse this file to extract the relevant macros becomes
+uncomfortable. Ideally, some of them should be contributed to
+Autoconf so that they can be used directly, however Autoconf is
+currently inactive. Automake 1.2 consequently introduces
+@command{aclocal} (@command{aclocal} was actually started on
+1996-07-28), a tool that automatically constructs an @file{aclocal.m4}
+file from a repository of third-party macros. Because Autoconf has
+stalled, Automake also becomes a kind of repository for such
+third-party macros, even macros completely unrelated to Automake (for
+instance macros that fix broken Autoconf macros).
+
+The 1.2 release contains 20 macros, including the
+@code{AM_INIT_AUTOMAKE} macro that simplifies the creation of
+@file{configure.in}.
+
+Libtool is fully supported using @code{*_LTLIBRARIES}.
+
+The missing script is introduced by Fran@,cois Pinard; it is meant
+to be a better solution than @code{AM_MAINTAINER_MODE}
+(@pxref{maintainer-mode, , maintainer-mode, automake, GNU Automake}).
+
+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 @file{configure}-based,
+and Ian thought that adding conditionals to @command{automake} was
+simpler than doing all the work in @file{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 @command{automake} script has almost doubled: 6089 lines of Perl,
+plus 1294 lines of @file{Makefile} fragments.
+
+@item 1997-07-08 Gordon Matzigkeit releases Libtool 1.0.
+
+@item 1998-04-05 Automake 1.3
+
+This is a small advance compared to 1.2.
+It adds support for assembly, and preliminary support for Java.
+
+Perl 5.004_04 is out, but fixes to support Perl 4 are still
+regularly submitted whenever Automake breaks it.
+
+@item 1998-09-06 @code{sourceware.cygnus.com} is on-line.
+
+Sourceware was setup by Jason Molenda to host open source projects.
+
+@item 1998-09-19 Automake CVS repository moved to @code{sourceware.cygnus.com}
+@itemx 1998-10-26 @code{sourceware.cygnus.com} announces it hosts Automake:
+Automake is now hosted on @code{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 @code{savannah.gnu.org},
+but the Sourceware host had been renamed to @code{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 @command{automake} and @command{autoconf} had joined
+@command{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.
+
+@item 1999-01-05 Ben Elliston releases Autoconf 2.13.
+
+@item 1999-01-14 Automake 1.4
+
+This release adds support for Fortran 77 and for the @code{include}
+statement. Also, @samp{+=} 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.
+
+@command{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.
+
+@item 1999-03-27 The @code{user-dep-branch} is created on the CVS repository.
+
+This implements a new dependency tracking schemed that should be
+able to handle automatic dependency tracking using any compiler (not
+just gcc) and any make (not just GNU @command{make}). In addition,
+the new scheme should be more reliable than the old one, as
+dependencies are generated on the end user's machine. Alexandre Oliva
+creates depcomp for this purpose.
+
+@xref{Dependency Tracking Evolution}, for more details about the
+evolution of automatic dependency tracking in Automake.
+
+@item 1999-11-21 The @code{user-dep-branch} is merged into the main trunk.
+
+This was a huge problem since we also had patches going in on the
+trunk. The merge took a long time and was very painful.
+
+@item 2000-05-10
+
+Since September 1999 and until 2003, Akim Demaille will be zealously
+revamping Autoconf.
+
+@quotation
+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{autoconf@@gnu.org}
+@end quotation
+
+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.
+
+@item 2001-01-24
+
+On this Wednesday, Autoconf 2.49c, the last beta before Autoconf 2.50
+is out, and Akim has to find something to do during his week-end :)
+
+@item 2001-01-28
+
+Akim sends a batch of 14 patches to @email{automake@@gnu.org}.
+
+@quotation
+Aiieeee! I was dreading the day that the Demaillator turned his
+sights on automake@dots{} and now it has arrived! -- Tom Tromey
+@end quotation
+
+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.
+
+@quotation
+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
+@end quotation
+
+All these patches were sent to and discussed on
+@email{automake@@gnu.org}, so subscribed users were literally drowning in
+technical mails. Eventually, the @email{automake-patches@@gnu.org}
+mailing list was created in May.
+
+Year after year, Automake had drifted away from its initial design:
+construct @file{Makefile.in} by assembling various @file{Makefile}
+fragments. In 1.4, lots of @file{Makefile} rules are being emitted at
+various places in the @command{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
+@file{Makefile} fragments, so the logic could be centralized in a
+@file{Makefile} fragment processor.
+
+Another significant contribution of Akim is the interface with the
+``trace'' feature of Autoconf. The way to scan @file{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; @command{automake}
+could miss some definition (for instance @samp{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 @option{--trace} option, which provides accurate information about
+where macros are actually called and with what arguments. Akim will
+equip Automake with a second @file{configure.in} scanner that uses
+this @option{--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.
+
+@item 2001-04-25 Gary V.@tie{}Vaughan releases Libtool 1.4
+
+It has been more than two years since Automake 1.4, CVS Automake has
+suffered lot's of heavy changes and still is not ready for release.
+Libtool 1.4 had to be distributed with a patch against Automake 1.4.
+
+@item 2001-05-08 Automake 1.4-p1
+@itemx 2001-05-24 Automake 1.4-p2
+
+Gary V.@tie{}Vaughan, the principal Libtool maintainer, makes a ``patch
+release'' of Automake:
+
+@quotation
+The main purpose of this release is to have a stable automake
+which is compatible with the latest stable libtool.
+@end quotation
+
+The release also contains obvious fixes for bugs in Automake 1.4,
+some of which were reported almost monthly.
+
+@item 2001-05-21 Akim Demaille releases Autoconf 2.50
+
+@item 2001-06-07 Automake 1.4-p3
+@itemx 2001-06-10 Automake 1.4-p4
+@itemx 2001-07-15 Automake 1.4-p5
+
+Gary continues his patch-release series. These also add support for
+some new Autoconf 2.50 idioms. Essentially, Autoconf now advocates
+@file{configure.ac} over @file{configure.in}, and it introduces a new
+syntax for @code{AC_OUTPUT}ing files.
+
+@item 2001-08-23 Automake 1.5
+
+A major and long-awaited release, that comes more than two years after
+1.4. It brings many changes, among which:
+@itemize
+@item The new dependency tracking scheme that uses @command{depcomp}.
+Aside from the improvement on the dependency tracking itself
+(@pxref{Dependency Tracking Evolution}), this also streamlines the use
+of @command{automake}-generated @file{Makefile.in}s as the @file{Makefile.in}s
+used during development are now the same as those used in
+distributions. Before that the @file{Makefile.in}s generated for
+maintainers required GNU @command{make} and GCC, they were different
+from the portable @file{Makefile} generated for distribution; this was
+causing some confusion.
+
+@item Support for per-target compilation flags.
+
+@item Support for reference to files in subdirectories in most
+@file{Makefile.am} variables.
+
+@item Introduction of the @code{dist_}, @code{nodist_}, and @code{nobase_}
+prefixes.
+@item Perl 4 support is finally dropped.
+@end itemize
+
+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
+@command{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, @samp{make distcheck} was
+improved to check that @samp{make uninstall} did remove all the files
+@samp{make install} installed, that @samp{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 @samp{+=} 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.
+
+@item 2002-03-05 Automake 1.6
+
+This release introduced versioned installation (@pxref{API Versioning, ,
+API Versioning, automake, GNU Automake}). This was mainly pushed by
+Havoc Pennington, taking the GNOME source tree as motive: due to
+incompatibilities between the autotools it's impossible for the GNOME
+packages to switch to Autoconf 2.53 and Automake 1.5 all at once, so
+they are currently stuck with Autoconf 2.13 and Automake 1.4.
+
+The idea was to call this version @file{automake-1.6}, call all its
+bug-fix versions identically, and switch to @file{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.
+
+@item 2002-04-11 Automake 1.6.1
+
+1.6, and the upcoming 1.4-p6 release were the last release by Tom.
+This one and those following will be handled by Alexandre
+Duret-Lutz. Tom is still around, and will be there until about 1.7,
+but his interest into Automake is drifting away towards projects like
+@command{gcj}.
+
+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.
+
+@item 2002-06-14 Automake 1.6.2
+
+@item 2002-07-28 Automake 1.6.3
+@itemx 2002-07-28 Automake 1.4-p6
+
+Two releases on the same day. 1.6.3 is a bug-fix release.
+
+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.
+
+@item 2002-09-25 Automake 1.7
+
+This release switches to the new @file{configure.ac} scanner Akim
+was experimenting in 1.5.
+
+@item 2002-10-16 Automake 1.7.1
+@itemx 2002-12-06 Automake 1.7.2
+@itemx 2003-02-20 Automake 1.7.3
+@itemx 2003-04-23 Automake 1.7.4
+@itemx 2003-05-18 Automake 1.7.5
+@itemx 2003-07-10 Automake 1.7.6
+@itemx 2003-09-07 Automake 1.7.7
+@itemx 2003-10-07 Automake 1.7.8
+
+Many bug-fix releases. 1.7 lasted because the development version
+(upcoming 1.8) was suffering some major internal revamping.
+
+@item 2003-10-26 Automake on screen
+
+Episode 49, `Repercussions', in the third season of the `Alias' TV
+show is first aired.
+
+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 @file{Makefile.in} generated by automake...
+
+@item 2003-11-09 Automake 1.7.9
+
+@item 2003-12-10 Automake 1.8
+
+The most striking update is probably that of @command{aclocal}.
+
+@command{aclocal} now uses @code{m4_include} in the produced
+@file{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: @file{Makefile.in}
+must be rebuilt whenever a dependency of @file{configure} changes, but
+all the @file{m4} files included in @file{aclocal.m4} where unknown
+from @command{automake}. Now @command{automake} can just trace the
+@code{m4_include}s to discover the dependencies.
+
+@command{aclocal} also starts using the @option{--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
+@command{aclocal} versions, notably using handwritten
+@code{m4_include}s: @command{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.
+
+@itemx 2004-01-11 Automake 1.8.1
+@itemx 2004-01-12 Automake 1.8.2
+@itemx 2004-03-07 Automake 1.8.3
+@itemx 2004-04-25 Automake 1.8.4
+@itemx 2004-05-16 Automake 1.8.5
+
+@item 2004-07-28 Automake 1.9
+
+This release tries to simplify the compilation rules it outputs to
+reduce the size of the Makefile. The complaint initially come from
+the libgcj developers. Their @file{Makefile.in} generated with
+Automake 1.4 and custom build rules (1.4 did not support compiled
+Java) is 250KB@. The one generated by 1.8 was over 9MB@! 1.9 gets it
+down to 1.2MB@.
+
+Aside from this it contains mainly minor changes and bug-fixes.
+
+@itemx 2004-08-11 Automake 1.9.1
+@itemx 2004-09-19 Automake 1.9.2
+
+Automake has ten years. This chapter of the manual was initially
+written for this occasion.
+
+@itemx 2007-10-29 Automake repository moves to @code{savannah.gnu.org}
+and uses git as primary repository.
+
+@end table
+
+@node Dependency Tracking Evolution
+@chapter Evolution of Automatic Dependency Tracking
+
+Over the years Automake has deployed three different dependency
+tracking methods. Each method, including the current one, has had
+flaws of various sorts. Here we lay out the different dependency
+tracking methods, their flaws, and their fixes. We conclude with
+recommendations for tool writers, and by indicating future directions
+for dependency tracking work in Automake.
+
+@menu
+* First Take on Dependencies:: Precomputed dependency tracking
+* Dependencies As Side Effects:: Update at developer compile time
+* Dependencies for the User:: Update at user compile time
+* Techniques for Dependencies:: Alternative approaches
+@end menu
+
+@node First Take on Dependencies
+@section First Take on Dependency Tracking
+@unnumberedsubsec Description
+
+Our first attempt at automatic dependency tracking was based on the
+method recommended by GNU @command{make}. (@pxref{Automatic
+Prerequisites, , Generating Prerequisites Automatically, make, The GNU
+make Manual})
+
+This version worked by precomputing dependencies ahead of time. For
+each source file, it had a special @file{.P} file that held the
+dependencies. There was a rule to generate a @file{.P} file by
+invoking the compiler appropriately. All such @file{.P} files were
+included by the @file{Makefile}, thus implicitly becoming dependencies
+of @file{Makefile}.
+
+@unnumberedsubsec Bugs
+
+This approach had several critical bugs.
+
+@itemize
+@item
+The code to generate the @file{.P} file relied on @command{gcc}.
+(A limitation, not technically a bug.)
+@item
+The dependency tracking mechanism itself relied on GNU @command{make}.
+(A limitation, not technically a bug.)
+@item
+Because each @file{.P} file was a dependency of @file{Makefile}, this
+meant that dependency tracking was done eagerly by @command{make}.
+For instance, @samp{make clean} would cause all the dependency files
+to be updated, and then immediately removed. This eagerness also
+caused problems with some configurations; if a certain source file
+could not be compiled on a given architecture for some reason,
+dependency tracking would fail, aborting the entire build.
+@item
+As dependency tracking was done as a pre-pass, compile times were
+doubled--the compiler had to be run twice per source file.
+@item
+@samp{make dist} re-ran @command{automake} to generate a
+@file{Makefile} that did not have automatic dependency tracking (and
+that was thus portable to any version of @command{make}). In order to
+do this portably, Automake had to scan the dependency files and remove
+any reference that was to a source file not in the distribution.
+This process was error-prone. Also, if @samp{make dist} was run in an
+environment where some object file had a dependency on a source file
+that was only conditionally created, Automake would generate a
+@file{Makefile} that referred to a file that might not appear in the
+end user's build. A special, hacky mechanism was required to work
+around this.
+@end itemize
+
+@unnumberedsubsec Historical Note
+
+The code generated by Automake is often inspired by the
+@file{Makefile} style of a particular author. In the case of the first
+implementation of dependency tracking, I believe the impetus and
+inspiration was Jim Meyering. (I could be mistaken. If you know
+otherwise feel free to correct me.)
+
+@node Dependencies As Side Effects
+@section Dependencies As Side Effects
+@unnumberedsubsec Description
+
+The next refinement of Automake's automatic dependency tracking scheme
+was to implement dependencies as side effects of the compilation.
+This was aimed at solving the most commonly reported problems with the
+first approach. In particular we were most concerned with eliminating
+the weird rebuilding effect associated with make clean.
+
+In this approach, the @file{.P} files were included using the
+@code{-include} command, which let us create these files lazily. This
+avoided the @samp{make clean} problem.
+
+We only computed dependencies when a file was actually compiled. This
+avoided the performance penalty associated with scanning each file
+twice. It also let us avoid the other problems associated with the
+first, eager, implementation. For instance, dependencies would never
+be generated for a source file that was not compilable on a given
+architecture (because it in fact would never be compiled).
+
+@unnumberedsubsec Bugs
+
+@itemize
+@item
+This approach also relied on the existence of @command{gcc} and GNU
+@command{make}. (A limitation, not technically a bug.)
+@item
+Dependency tracking was still done by the developer, so the problems
+from the first implementation relating to massaging of dependencies by
+@samp{make dist} were still in effect.
+@item
+This implementation suffered from the ``deleted header file'' problem.
+Suppose a lazily-created @file{.P} file includes a dependency on a
+given header file, like this:
+
+@example
+maude.o: maude.c something.h
+@end example
+
+Now suppose that you remove @file{something.h} and update @file{maude.c}
+so that this include is no longer needed. If you run @command{make},
+you will get an error because there is no way to create
+@file{something.h}.
+
+We fixed this problem in a later release by further massaging the
+output of @command{gcc} to include a dummy dependency for each header
+file.
+@end itemize
+
+@node Dependencies for the User
+@section Dependencies for the User
+@unnumberedsubsec Description
+
+The bugs associated with @samp{make dist}, over time, became a real
+problem. Packages using Automake were being built on a large number
+of platforms, and were becoming increasingly complex. Broken
+dependencies were distributed in ``portable'' @file{Makefile.in}s,
+leading to user complaints. Also, the requirement for @command{gcc}
+and GNU @command{make} was a constant source of bug reports. The next
+implementation of dependency tracking aimed to remove these problems.
+
+We realized that the only truly reliable way to automatically track
+dependencies was to do it when the package itself was built. This
+meant discovering a method portable to any version of make and any
+compiler. Also, we wanted to preserve what we saw as the best point
+of the second implementation: dependency computation as a side effect
+of compilation.
+
+In the end we found that most modern make implementations support some
+form of include directive. Also, we wrote a wrapper script that let
+us abstract away differences between dependency tracking methods for
+compilers. For instance, some compilers cannot generate dependencies
+as a side effect of compilation. In this case we simply have the
+script run the compiler twice. Currently our wrapper script
+(@command{depcomp}) knows about twelve different compilers (including
+a "compiler" that simply invokes @command{makedepend} and then the
+real compiler, which is assumed to be a standard Unix-like C compiler
+with no way to do dependency tracking).
+
+@unnumberedsubsec Bugs
+
+@itemize
+@item
+Running a wrapper script for each compilation slows down the build.
+@item
+Many users don't really care about precise dependencies.
+@item
+This implementation, like every other automatic dependency tracking
+scheme in common use today (indeed, every one we've ever heard of),
+suffers from the ``duplicated new header'' bug.
+
+This bug occurs because dependency tracking tools, such as the
+compiler, only generate dependencies on the successful opening of a
+file, and not on every probe.
+
+Suppose for instance that the compiler searches three directories for
+a given header, and that the header is found in the third directory.
+If the programmer erroneously adds a header file with the same name to
+the first directory, then a clean rebuild from scratch could fail
+(suppose the new header file is buggy), whereas an incremental rebuild
+will succeed.
+
+What has happened here is that people have a misunderstanding of what
+a dependency is. Tool writers think a dependency encodes information
+about which files were read by the compiler. However, a dependency
+must actually encode information about what the compiler tried to do.
+
+This problem is not serious in practice. Programmers typically do not
+use the same name for a header file twice in a given project. (At
+least, not in C or C++. This problem may be more troublesome in
+Java.) This problem is easy to fix, by modifying dependency
+generators to record every probe, instead of every successful open.
+
+@item
+Since Automake generates dependencies as a side effect of compilation,
+there is a bootstrapping problem when header files are generated by
+running a program. The problem is that, the first time the build is
+done, there is no way by default to know that the headers are
+required, so make might try to run a compilation for which the headers
+have not yet been built.
+
+This was also a problem in the previous dependency tracking implementation.
+
+The current fix is to use @code{BUILT_SOURCES} to list built headers
+(@pxref{Sources, , Sources, automake, GNU Automake}). This causes them
+to be built before any other build rules are run. This is unsatisfactory
+as a general solution, however in practice it seems sufficient for most
+actual programs.
+@end itemize
+
+This code is used since Automake 1.5.
+
+In GCC 3.0, we managed to convince the maintainers to add special
+command-line options to help Automake more efficiently do its job. We
+hoped this would let us avoid the use of a wrapper script when
+Automake's automatic dependency tracking was used with @command{gcc}.
+
+Unfortunately, this code doesn't quite do what we want. In
+particular, it removes the dependency file if the compilation fails;
+we'd prefer that it instead only touch the file in any way if the
+compilation succeeds.
+
+Nevertheless, since Automake 1.7, when a recent @command{gcc} is
+detected at @command{configure} time, we inline the
+dependency-generation code and do not use the @command{depcomp}
+wrapper script. This makes compilations faster for those using this
+compiler (probably our primary user base). The counterpart is that
+because we have to encode two compilation rules in @file{Makefile}
+(with or without @command{depcomp}), the produced @file{Makefile}s are
+larger.
+
+@node Techniques for Dependencies
+@section Techniques for Computing Dependencies
+
+There are actually several ways for a build tool like Automake to
+cause tools to generate dependencies.
+
+@table @asis
+@item @command{makedepend}
+This was a commonly-used method in the past. The idea is to run a
+special program over the source and have it generate dependency
+information. Traditional implementations of @command{makedepend} are
+not completely precise; ordinarily they were conservative and
+discovered too many dependencies.
+@item The tool
+An obvious way to generate dependencies is to simply write the tool so
+that it can generate the information needed by the build tool. This is
+also the most portable method. Many compilers have an option to
+generate dependencies. Unfortunately, not all tools provide such an
+option.
+@item The file system
+It is possible to write a special file system that tracks opens,
+reads, writes, etc, and then feed this information back to the build
+tool. @command{clearmake} does this. This is a very powerful
+technique, as it doesn't require cooperation from the
+tool. Unfortunately it is also very difficult to implement and also
+not practical in the general case.
+@item @code{LD_PRELOAD}
+Rather than use the file system, one could write a special library to
+intercept @code{open} and other syscalls. This technique is also quite
+powerful, but unfortunately it is not portable enough for use in
+@command{automake}.
+@end table
+
+@menu
+* Recommendations for Tool Writers::
+* Future Directions for Dependencies::
+@end menu
+
+@node Recommendations for Tool Writers
+@subsection Recommendations for Tool Writers
+
+We think that every compilation tool ought to be able to generate
+dependencies as a side effect of compilation. Furthermore, at least
+while @command{make}-based tools are nearly universally in use (at
+least in the free software community), the tool itself should generate
+dummy dependencies for header files, to avoid the deleted header file
+bug. Finally, the tool should generate a dependency for each probe,
+instead of each successful file open, in order to avoid the duplicated
+new header bug.
+
+@node Future Directions for Dependencies
+@subsection Future Directions for Dependencies
+
+Currently, only languages and compilers understood by Automake can
+have dependency tracking enabled. We would like to see if it is
+practical (and worthwhile) to let this support be extended by the user
+to languages unknown to Automake.
+
+@node Releases
+@chapter Release Statistics
+
+The following table (inspired by @samp{perlhist(1)}) quantifies the
+evolution of Automake using these metrics:
+
+@table @asis
+@item Date, Rel
+The date and version of the release.
+@item am
+The number of lines of the @command{automake} script.
+@item acl
+The number of lines of the @command{aclocal} script.
+@item pm
+The number of lines of the @command{Perl} supporting modules.
+@item @file{*.am}
+The number of lines of the @file{Makefile} fragments. The number in
+parentheses is the number of files.
+@item m4
+The number of lines (and files) of Autoconf macros.
+@item doc
+The number of pages of the documentation (the Postscript version).
+@item t
+The number of test cases in the test suite. Of those, the number in
+parentheses is the number of generated test cases.
+@end table
+
+@multitable {8888-88-88} {8.8-p8} {8888} {8888} {8888} {8888 (88)} {8888 (88)} {888} {888 (88)}
+@headitem Date @tab Rel @tab am @tab acl @tab pm @tab @file{*.am} @tab m4 @tab doc @tab t
+@item 1994-09-19 @tab CVS @tab 141 @tab @tab @tab 299 (24) @tab @tab @tab
+@item 1994-11-05 @tab CVS @tab 208 @tab @tab @tab 332 (28) @tab @tab @tab
+@item 1995-11-23 @tab 0.20 @tab 533 @tab @tab @tab 458 (35) @tab @tab 9 @tab
+@item 1995-11-26 @tab 0.21 @tab 613 @tab @tab @tab 480 (36) @tab @tab 11 @tab
+@item 1995-11-28 @tab 0.22 @tab 1116 @tab @tab @tab 539 (38) @tab @tab 12 @tab
+@item 1995-11-29 @tab 0.23 @tab 1240 @tab @tab @tab 541 (38) @tab @tab 12 @tab
+@item 1995-12-08 @tab 0.24 @tab 1462 @tab @tab @tab 504 (33) @tab @tab 14 @tab
+@item 1995-12-10 @tab 0.25 @tab 1513 @tab @tab @tab 511 (37) @tab @tab 15 @tab
+@item 1996-01-03 @tab 0.26 @tab 1706 @tab @tab @tab 438 (36) @tab @tab 16 @tab
+@item 1996-01-03 @tab 0.27 @tab 1706 @tab @tab @tab 438 (36) @tab @tab 16 @tab
+@item 1996-01-13 @tab 0.28 @tab 1964 @tab @tab @tab 934 (33) @tab @tab 16 @tab
+@item 1996-02-07 @tab 0.29 @tab 2299 @tab @tab @tab 936 (33) @tab @tab 17 @tab
+@item 1996-02-24 @tab 0.30 @tab 2544 @tab @tab @tab 919 (32) @tab 85 (1) @tab 20 @tab 9
+@item 1996-03-11 @tab 0.31 @tab 2877 @tab @tab @tab 919 (32) @tab 85 (1) @tab 29 @tab 17
+@item 1996-04-27 @tab 0.32 @tab 3058 @tab @tab @tab 921 (31) @tab 85 (1) @tab 30 @tab 26
+@item 1996-05-18 @tab 0.33 @tab 3110 @tab @tab @tab 926 (31) @tab 105 (1) @tab 30 @tab 35
+@item 1996-05-28 @tab 1.0 @tab 3134 @tab @tab @tab 973 (32) @tab 105 (1) @tab 30 @tab 38
+@item 1997-06-22 @tab 1.2 @tab 6089 @tab 385 @tab @tab 1294 (36) @tab 592 (20) @tab 37 @tab 126
+@item 1998-04-05 @tab 1.3 @tab 6415 @tab 422 @tab @tab 1470 (39) @tab 741 (23) @tab 39 @tab 156
+@item 1999-01-14 @tab 1.4 @tab 7240 @tab 426 @tab @tab 1591 (40) @tab 734 (20) @tab 51 @tab 197
+@item 2001-05-08 @tab 1.4-p1 @tab 7251 @tab 426 @tab @tab 1591 (40) @tab 734 (20) @tab 51 @tab 197
+@item 2001-05-24 @tab 1.4-p2 @tab 7268 @tab 439 @tab @tab 1591 (40) @tab 734 (20) @tab 49 @tab 197
+@item 2001-06-07 @tab 1.4-p3 @tab 7312 @tab 439 @tab @tab 1591 (40) @tab 734 (20) @tab 49 @tab 197
+@item 2001-06-10 @tab 1.4-p4 @tab 7321 @tab 439 @tab @tab 1591 (40) @tab 734 (20) @tab 49 @tab 198
+@item 2001-07-15 @tab 1.4-p5 @tab 7228 @tab 426 @tab @tab 1596 (40) @tab 734 (20) @tab 51 @tab 198
+@item 2001-08-23 @tab 1.5 @tab 8016 @tab 475 @tab 600 @tab 2654 (39) @tab 1166 (29) @tab 63 @tab 327
+@item 2002-03-05 @tab 1.6 @tab 8465 @tab 475 @tab 1136 @tab 2732 (39) @tab 1603 (27) @tab 66 @tab 365
+@item 2002-04-11 @tab 1.6.1 @tab 8544 @tab 475 @tab 1136 @tab 2741 (39) @tab 1603 (27) @tab 66 @tab 372
+@item 2002-06-14 @tab 1.6.2 @tab 8575 @tab 475 @tab 1136 @tab 2800 (39) @tab 1609 (27) @tab 67 @tab 386
+@item 2002-07-28 @tab 1.6.3 @tab 8600 @tab 475 @tab 1153 @tab 2809 (39) @tab 1609 (27) @tab 67 @tab 391
+@item 2002-07-28 @tab 1.4-p6 @tab 7332 @tab 455 @tab @tab 1596 (40) @tab 735 (20) @tab 49 @tab 197
+@item 2002-09-25 @tab 1.7 @tab 9189 @tab 471 @tab 1790 @tab 2965 (39) @tab 1606 (28) @tab 73 @tab 430
+@item 2002-10-16 @tab 1.7.1 @tab 9229 @tab 475 @tab 1790 @tab 2977 (39) @tab 1606 (28) @tab 73 @tab 437
+@item 2002-12-06 @tab 1.7.2 @tab 9334 @tab 475 @tab 1790 @tab 2988 (39) @tab 1606 (28) @tab 77 @tab 445
+@item 2003-02-20 @tab 1.7.3 @tab 9389 @tab 475 @tab 1790 @tab 3023 (39) @tab 1651 (29) @tab 84 @tab 448
+@item 2003-04-23 @tab 1.7.4 @tab 9429 @tab 475 @tab 1790 @tab 3031 (39) @tab 1644 (29) @tab 85 @tab 458
+@item 2003-05-18 @tab 1.7.5 @tab 9429 @tab 475 @tab 1790 @tab 3033 (39) @tab 1645 (29) @tab 85 @tab 459
+@item 2003-07-10 @tab 1.7.6 @tab 9442 @tab 475 @tab 1790 @tab 3033 (39) @tab 1660 (29) @tab 85 @tab 461
+@item 2003-09-07 @tab 1.7.7 @tab 9443 @tab 475 @tab 1790 @tab 3041 (39) @tab 1660 (29) @tab 90 @tab 467
+@item 2003-10-07 @tab 1.7.8 @tab 9444 @tab 475 @tab 1790 @tab 3041 (39) @tab 1660 (29) @tab 90 @tab 468
+@item 2003-11-09 @tab 1.7.9 @tab 9444 @tab 475 @tab 1790 @tab 3048 (39) @tab 1660 (29) @tab 90 @tab 468
+@item 2003-12-10 @tab 1.8 @tab 7171 @tab 585 @tab 7730 @tab 3236 (39) @tab 1666 (31) @tab 104 @tab 521
+@item 2004-01-11 @tab 1.8.1 @tab 7217 @tab 663 @tab 7726 @tab 3287 (39) @tab 1686 (31) @tab 104 @tab 525
+@item 2004-01-12 @tab 1.8.2 @tab 7217 @tab 663 @tab 7726 @tab 3288 (39) @tab 1686 (31) @tab 104 @tab 526
+@item 2004-03-07 @tab 1.8.3 @tab 7214 @tab 686 @tab 7735 @tab 3303 (39) @tab 1695 (31) @tab 111 @tab 530
+@item 2004-04-25 @tab 1.8.4 @tab 7214 @tab 686 @tab 7736 @tab 3310 (39) @tab 1701 (31) @tab 112 @tab 531
+@item 2004-05-16 @tab 1.8.5 @tab 7240 @tab 686 @tab 7736 @tab 3299 (39) @tab 1701 (31) @tab 112 @tab 533
+@item 2004-07-28 @tab 1.9 @tab 7508 @tab 715 @tab 7794 @tab 3352 (40) @tab 1812 (32) @tab 115 @tab 551
+@item 2004-08-11 @tab 1.9.1 @tab 7512 @tab 715 @tab 7794 @tab 3354 (40) @tab 1812 (32) @tab 115 @tab 552
+@item 2004-09-19 @tab 1.9.2 @tab 7512 @tab 715 @tab 7794 @tab 3354 (40) @tab 1812 (32) @tab 132 @tab 554
+@item 2004-11-01 @tab 1.9.3 @tab 7507 @tab 718 @tab 7804 @tab 3354 (40) @tab 1812 (32) @tab 134 @tab 556
+@item 2004-12-18 @tab 1.9.4 @tab 7508 @tab 718 @tab 7856 @tab 3361 (40) @tab 1811 (32) @tab 140 @tab 560
+@item 2005-02-13 @tab 1.9.5 @tab 7523 @tab 719 @tab 7859 @tab 3373 (40) @tab 1453 (32) @tab 142 @tab 562
+@item 2005-07-10 @tab 1.9.6 @tab 7539 @tab 699 @tab 7867 @tab 3400 (40) @tab 1453 (32) @tab 144 @tab 570
+@item 2006-10-15 @tab 1.10 @tab 7859 @tab 1072 @tab 8024 @tab 3512 (40) @tab 1496 (34) @tab 172 @tab 604
+@item 2008-01-19 @tab 1.10.1 @tab 7870 @tab 1089 @tab 8025 @tab 3520 (40) @tab 1499 (34) @tab 173 @tab 617
+@item 2008-11-23 @tab 1.10.2 @tab 7882 @tab 1089 @tab 8027 @tab 3540 (40) @tab 1509 (34) @tab 176 @tab 628
+@item 2009-05-17 @tab 1.11 @tab 8721 @tab 1092 @tab 8289 @tab 4164 (42) @tab 1714 (37) @tab 181 @tab 732 (20)
+@end multitable
+
+
+@c ========================================================== Appendices
+
+@page
+@node Copying This Manual
+@appendix Copying This Manual
+
+@menu
+* GNU Free Documentation License:: License for copying this manual
+@end menu
+
+@node GNU Free Documentation License
+@appendixsec GNU Free Documentation License
+@include fdl.texi
+
+@bye
* API Versioning:: About compatibility between Automake versions
* Upgrading:: Upgrading to a Newer Automake Version
* FAQ:: Frequently Asked Questions
-* History:: Notes about the history of Automake
* Copying This Manual:: How to make copies of this manual
* Indices:: Indices of variables, macros, and concepts
* Debugging Make Rules:: Strategies when things don't work as expected
* Reporting Bugs:: Feedback on bugs and feature requests
-History of Automake
-
-* Timeline:: The Automake story.
-* Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking
-* Releases:: Statistics about Automake Releases
-
-Dependency Tracking in Automake
-
-* First Take on Dependencies:: Precomputed dependency tracking
-* Dependencies As Side Effects:: Update at developer compile time
-* Dependencies for the User:: Update at user compile time
-* Techniques for Dependencies:: Alternative approaches
-* Recommendations for Tool Writers:: What tool writers can do to help
-* Future Directions for Dependencies:: Languages Automake does not know
-
Copying This Manual
* GNU Free Documentation License:: License for copying this manual
Do not reject slow dependency extractors.
@end table
-@xref{Dependency Tracking Evolution}, for some discussion about the
-different dependency tracking schemes used by Automake over the years.
+@xref{Dependency Tracking Evolution, , Dependency Tracking Evolution,
+automake-history, Brief History of Automake}, for some discussion about
+the different dependency tracking schemes used by Automake over the years.
@node Nested Packages
@subsection Nested Packages
@cindex @command{depcomp}
-Experience with earlier versions of Automake (@pxref{Dependency
-Tracking Evolution}) taught us that it is not reliable to generate
-dependencies only on the maintainer's system, as configurations vary
-too much. So instead Automake implements dependency tracking at build
-time.
+Experience with earlier versions of Automake (@pxref{Dependency Tracking
+Evolution, , Dependency Tracking Evolution, automake-history, Brief History
+of Automake}) taught us that it is not reliable to generate dependencies
+only on the maintainer's system, as configurations vary too much. So
+instead Automake implements dependency tracking at build time.
Automatic dependency tracking can be suppressed by putting
@option{no-dependencies} in the variable @code{AUTOMAKE_OPTIONS}, or
reproduces the problem you encounter. If you have encountered test
suite failures, please attach the @file{tests/test-suite.log} file.
-
-@node History
-@chapter History of Automake
-
-This chapter presents various aspects of the history of Automake. The
-exhausted reader can safely skip it; this will be more of interest to
-nostalgic people, or to those curious to learn about the evolution of
-Automake.
-
-@menu
-* Timeline:: The Automake story.
-* Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking
-* Releases:: Statistics about Automake Releases
-@end menu
-
-@node Timeline
-@section Timeline
-
-@table @asis
-@item 1994-09-19 First CVS commit.
-
-If we can trust the CVS repository, David J.@tie{}MacKenzie (djm) started
-working on Automake (or AutoMake, as it was spelt then) this Monday.
-
-The first version of the @command{automake} script looks as follows.
-
-@example
-#!/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
-@end example
-
-From this you can already see that Automake will be about reading
-@file{*.am} file and producing @file{*.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 @file{Makefile.am} files trigger injections of
-precanned @file{Makefile} fragments into the generated
-@file{Makefile.in}. The use of @file{Makefile} fragments was inspired
-by the 4.4BSD @command{make} and include files, however Automake aims
-to be portable and to conform to the GNU standards for @file{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.
-
-@item 1994-11-05 David MacKenzie's last commit.
-
-At this point Automake is a 200 line portable shell script, plus 332
-lines of @file{Makefile} fragments. In the @file{README}, David
-states his ambivalence between ``portable shell'' and ``more
-appropriate language'':
-
-@quotation
-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.
-@end quotation
-
-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.
-
-@item 1995-11-12 Tom Tromey's first commit.
-
-After one year of inactivity, Tom Tromey takes over the package.
-Tom was working on GNU cpio back then, and doing this just for fun,
-having trouble finding a project to contribute to. So while hacking
-he wanted to bring the @file{Makefile.in} up to GNU standards. This
-was hard, and one day he saw Automake on @url{ftp://alpha.gnu.org/},
-grabbed it and tried it out.
-
-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@,cois 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.
-
-@item 1995-11-23 Automake 0.20
-
-Besides introducing automatic dependency tracking (@pxref{Dependency
-Tracking Evolution}), this version also supplies a 9-page manual.
-
-At this time @command{aclocal} and @code{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
-@file{configure.ac} we use today) must contain in order to use
-Automake 0.20:
-
-@example
-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
-@end example
-
-(Today all of the above is achieved by @code{AC_INIT} and
-@code{AM_INIT_AUTOMAKE}.)
-
-Here is how programs are specified in @file{Makefile.am}:
-
-@example
-PROGRAMS = hello
-hello_SOURCES = hello.c
-@end example
-
-This looks pretty much like what we do today, except the
-@code{PROGRAMS} variable has no directory prefix specifying where
-@file{hello} should be installed: all programs are installed in
-@samp{$(bindir)}. @code{LIBPROGRAMS} can be used to specify programs
-that must be built but not installed (it is called
-@code{noinst_PROGRAMS} nowadays).
-
-Programs can be built conditionally using @code{AC_SUBST}itutions:
-
-@example
-PROGRAMS = @@progs@@
-AM_PROGRAMS = foo bar baz
-@end example
-
-(@code{AM_PROGRAMS} has since then been renamed to
-@code{EXTRA_PROGRAMS}.)
-
-Similarly scripts, static libraries, and data can be built and installed
-using the @code{LIBRARIES}, @code{SCRIPTS}, and @code{DATA} variables.
-However @code{LIBRARIES} were treated a bit specially in that Automake
-did automatically supply the @file{lib} and @file{.a} prefixes.
-Therefore to build @file{libcpio.a}, one had to write
-
-@example
-LIBRARIES = cpio
-cpio_SOURCES = ...
-@end example
-
-Extra files to distribute must be listed in @code{DIST_OTHER} (the
-ancestor of @code{EXTRA_DIST}). Also extra directories that are to be
-distributed should appear in @code{DIST_SUBDIRS}, but the manual
-describes this as a temporary ugly hack (today extra directories should
-also be listed in @code{EXTRA_DIST}, and @code{DIST_SUBDIRS} is used
-for another purpose, @pxref{Conditional Subdirectories}).
-
-@item 1995-11-26 Automake 0.21
-
-In less time than it takes to cook a frozen pizza, Tom rewrites
-Automake using Perl. At this time Perl 5 is only one year old, and
-Perl 4.036 is in use at many sites. Supporting several Perl versions
-has been a source of problems through the whole history of Automake.
-
-If you never used Perl 4, imagine Perl 5 without objects, without
-@samp{my} variables (only dynamically scoped @samp{local} variables),
-without function prototypes, with function calls that needs to be
-prefixed with @samp{&}, etc. Traces of this old style can still be
-found in today's @command{automake}.
-
-@item 1995-11-28 Automake 0.22
-@itemx 1995-11-29 Automake 0.23
-
-Bug fixes.
-
-@item 1995-12-08 Automake 0.24
-@itemx 1995-12-10 Automake 0.25
-
-Releases are raining. 0.24 introduces the uniform naming scheme we
-use today, i.e., @code{bin_PROGRAMS} instead of @code{PROGRAMS},
-@code{noinst_LIBRARIES} instead of @code{LIBLIBRARIES}, etc. (However
-@code{EXTRA_PROGRAMS} does not exist yet, @code{AM_PROGRAMS} is still
-in use; and @code{TEXINFOS} and @code{MANS} still have no directory
-prefixes.) Adding support for prefixes like that was one of the major
-ideas in @command{automake}; it has lasted pretty well.
-
-AutoMake is renamed to Automake (Tom seems to recall it was Fran@,cois
-Pinard's doing).
-
-0.25 fixes a Perl 4 portability bug.
-
-@item 1995-12-18 Jim Meyering starts using Automake in GNU Textutils.
-@item 1995-12-31 Fran@,cois Pinard starts using Automake in GNU tar.
-
-@item 1996-01-03 Automake 0.26
-@itemx 1996-01-03 Automake 0.27
-
-Of the many changes and suggestions sent by Fran@,cois Pinard and
-included in 0.26, perhaps the most important is the advice that to
-ease customization a user rule or variable definition should always
-override an Automake rule or definition.
-
-Gordon Matzigkeit and Jim Meyering are two other early contributors
-that have been sending fixes.
-
-0.27 fixes yet another Perl 4 portability bug.
-
-@item 1996-01-13 Automake 0.28
-
-Automake starts scanning @file{configure.in} for @code{LIBOBJS}
-support. This is an important step because until this version
-Automake only knew about the @file{Makefile.am}s it processed.
-@file{configure.in} was Autoconf's world and the link between Autoconf
-and Automake had to be done by the @file{Makefile.am} author. For
-instance, if @file{config.h} was generated by @file{configure}, it was the
-package maintainer's responsibility to define the @code{CONFIG_HEADER}
-variable in each @file{Makefile.am}.
-
-Succeeding releases will rely more and more on scanning
-@file{configure.in} to better automate the Autoconf integration.
-
-0.28 also introduces the @code{AUTOMAKE_OPTIONS} variable and the
-@option{--gnu} and @option{--gnits} options, the latter being stricter.
-
-@item 1996-02-07 Automake 0.29
-
-Thanks to @file{configure.in} scanning, @code{CONFIG_HEADER} is gone,
-and rebuild rules for @file{configure}-generated file are
-automatically output.
-
-@code{TEXINFOS} and @code{MANS} converted to the uniform naming
-scheme.
-
-@item 1996-02-24 Automake 0.30
-
-The test suite is born. It contains 9 tests. From now on test cases
-will be added pretty regularly (@pxref{Releases}), and this proved to
-be really helpful later on.
-
-@code{EXTRA_PROGRAMS} finally replaces @code{AM_PROGRAMS}.
-
-All the third-party Autoconf macros, written mostly by Fran@,cois
-Pinard (and later Jim Meyering), are distributed in Automake's
-hand-written @file{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...)
-
-@item 1996-03-11 Automake 0.31
-
-The test suite in 0.30 was run via a long @code{check-local} rule. Upon
-Ulrich Drepper's suggestion, 0.31 makes it an Automake rule output
-whenever the @code{TESTS} variable is defined.
-
-@code{DIST_OTHER} is renamed to @code{EXTRA_DIST}, and the @code{check_}
-prefix is introduced. The syntax is now the same as today.
-
-@item 1996-03-15 Gordon Matzigkeit starts writing libtool.
-
-@item 1996-04-27 Automake 0.32
-
-@code{-hook} targets are introduced; an idea from Dieter Baron.
-
-@file{*.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.
-
-@item 1996-05-18 Automake 0.33
-
-Gord Matzigkeit's main two contributions:
-
-@itemize
-@item very preliminary libtool support
-@item the distcheck rule
-@end itemize
-
-Although they were very basic at this point, these are probably
-among the top features for Automake today.
-
-Jim Meyering also provides the infamous @code{jm_MAINTAINER_MODE},
-since then renamed to @code{AM_MAINTAINER_MODE} and abandoned by its
-author (@pxref{maintainer-mode}).
-
-@item 1996-05-28 Automake 1.0
-
-After only six months of heavy development, the @command{automake} script is
-3134 lines long, plus 973 lines of @file{Makefile} fragments. The
-package has 30 pages of documentation, and 38 test cases.
-@file{aclocal.m4} contains 4 macros.
-
-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.
-
-@item 1996-10-10 Kevin Dalley packages Automake 1.0 for Debian GNU/Linux.
-
-@item 1996-11-26 David J.@tie{}MacKenzie releases Autoconf 2.12.
-
-Between June and October, the Autoconf development is almost stalled.
-Roland McGrath has been working at the beginning of the year. David
-comes back in November to release 2.12, but he won't touch Autoconf
-anymore after this year, and Autoconf then really stagnates. The
-desolate Autoconf @file{ChangeLog} for 1997 lists only 7 commits.
-
-@item 1997-02-28 @email{automake@@gnu.ai.mit.edu} list alive
-
-The mailing list is announced as follows:
-@smallexample
-I've created the "automake" mailing list. It is
-"automake@@gnu.ai.mit.edu". Administrivia, as always, to
-automake-request@@gnu.ai.mit.edu.
-
-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
-@end smallexample
-
-Before that people were discussing Automake privately, on the Gnits
-mailing list (which is not public either), and less frequently on
-@code{gnu.misc.discuss}.
-
-@code{gnu.ai.mit.edu} is now @code{gnu.org}, in case you never
-noticed. The archives of the early years of the
-@code{automake@@gnu.org} 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.
-
-@item 1997-06-22 Automake 1.2
-
-Automake developments continues, and more and more new Autoconf macros
-are required. Distributing them in @file{aclocal.m4} and requiring
-people to browse this file to extract the relevant macros becomes
-uncomfortable. Ideally, some of them should be contributed to
-Autoconf so that they can be used directly, however Autoconf is
-currently inactive. Automake 1.2 consequently introduces
-@command{aclocal} (@command{aclocal} was actually started on
-1996-07-28), a tool that automatically constructs an @file{aclocal.m4}
-file from a repository of third-party macros. Because Autoconf has
-stalled, Automake also becomes a kind of repository for such
-third-party macros, even macros completely unrelated to Automake (for
-instance macros that fix broken Autoconf macros).
-
-The 1.2 release contains 20 macros, including the
-@code{AM_INIT_AUTOMAKE} macro that simplifies the creation of
-@file{configure.in}.
-
-Libtool is fully supported using @code{*_LTLIBRARIES}.
-
-The missing script is introduced by Fran@,cois Pinard; it is meant to be
-a better solution than @code{AM_MAINTAINER_MODE}
-(@pxref{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 @file{configure}-based,
-and Ian thought that adding conditionals to @command{automake} was
-simpler than doing all the work in @file{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 @command{automake} script has almost doubled: 6089 lines of Perl,
-plus 1294 lines of @file{Makefile} fragments.
-
-@item 1997-07-08 Gordon Matzigkeit releases Libtool 1.0.
-
-@item 1998-04-05 Automake 1.3
-
-This is a small advance compared to 1.2.
-It adds support for assembly, and preliminary support for Java.
-
-Perl 5.004_04 is out, but fixes to support Perl 4 are still
-regularly submitted whenever Automake breaks it.
-
-@item 1998-09-06 @code{sourceware.cygnus.com} is on-line.
-
-Sourceware was setup by Jason Molenda to host open source projects.
-
-@item 1998-09-19 Automake CVS repository moved to @code{sourceware.cygnus.com}
-@itemx 1998-10-26 @code{sourceware.cygnus.com} announces it hosts Automake:
-Automake is now hosted on @code{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 @code{savannah.gnu.org},
-but the Sourceware host had been renamed to @code{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 @command{automake} and @command{autoconf} had joined
-@command{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.
-
-@item 1999-01-05 Ben Elliston releases Autoconf 2.13.
-
-@item 1999-01-14 Automake 1.4
-
-This release adds support for Fortran 77 and for the @code{include}
-statement. Also, @samp{+=} 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.
-
-@command{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.
-
-@item 1999-03-27 The @code{user-dep-branch} is created on the CVS repository.
-
-This implements a new dependency tracking schemed that should be
-able to handle automatic dependency tracking using any compiler (not
-just gcc) and any make (not just GNU @command{make}). In addition,
-the new scheme should be more reliable than the old one, as
-dependencies are generated on the end user's machine. Alexandre Oliva
-creates depcomp for this purpose.
-
-@xref{Dependency Tracking Evolution}, for more details about the
-evolution of automatic dependency tracking in Automake.
-
-@item 1999-11-21 The @code{user-dep-branch} is merged into the main trunk.
-
-This was a huge problem since we also had patches going in on the
-trunk. The merge took a long time and was very painful.
-
-@item 2000-05-10
-
-Since September 1999 and until 2003, Akim Demaille will be zealously
-revamping Autoconf.
-
-@quotation
-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{autoconf@@gnu.org}
-@end quotation
-
-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.
-
-@item 2001-01-24
-
-On this Wednesday, Autoconf 2.49c, the last beta before Autoconf 2.50
-is out, and Akim has to find something to do during his week-end :)
-
-@item 2001-01-28
-
-Akim sends a batch of 14 patches to @email{automake@@gnu.org}.
-
-@quotation
-Aiieeee! I was dreading the day that the Demaillator turned his
-sights on automake@dots{} and now it has arrived! -- Tom Tromey
-@end quotation
-
-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.
-
-@quotation
-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
-@end quotation
-
-All these patches were sent to and discussed on
-@email{automake@@gnu.org}, so subscribed users were literally drowning in
-technical mails. Eventually, the @email{automake-patches@@gnu.org}
-mailing list was created in May.
-
-Year after year, Automake had drifted away from its initial design:
-construct @file{Makefile.in} by assembling various @file{Makefile}
-fragments. In 1.4, lots of @file{Makefile} rules are being emitted at
-various places in the @command{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
-@file{Makefile} fragments, so the logic could be centralized in a
-@file{Makefile} fragment processor.
-
-Another significant contribution of Akim is the interface with the
-``trace'' feature of Autoconf. The way to scan @file{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; @command{automake}
-could miss some definition (for instance @samp{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 @option{--trace} option, which provides accurate information about
-where macros are actually called and with what arguments. Akim will
-equip Automake with a second @file{configure.in} scanner that uses
-this @option{--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.
-
-@item 2001-04-25 Gary V.@tie{}Vaughan releases Libtool 1.4
-
-It has been more than two years since Automake 1.4, CVS Automake has
-suffered lot's of heavy changes and still is not ready for release.
-Libtool 1.4 had to be distributed with a patch against Automake 1.4.
-
-@item 2001-05-08 Automake 1.4-p1
-@itemx 2001-05-24 Automake 1.4-p2
-
-Gary V.@tie{}Vaughan, the principal Libtool maintainer, makes a ``patch
-release'' of Automake:
-
-@quotation
-The main purpose of this release is to have a stable automake
-which is compatible with the latest stable libtool.
-@end quotation
-
-The release also contains obvious fixes for bugs in Automake 1.4,
-some of which were reported almost monthly.
-
-@item 2001-05-21 Akim Demaille releases Autoconf 2.50
-
-@item 2001-06-07 Automake 1.4-p3
-@itemx 2001-06-10 Automake 1.4-p4
-@itemx 2001-07-15 Automake 1.4-p5
-
-Gary continues his patch-release series. These also add support for
-some new Autoconf 2.50 idioms. Essentially, Autoconf now advocates
-@file{configure.ac} over @file{configure.in}, and it introduces a new
-syntax for @code{AC_OUTPUT}ing files.
-
-@item 2001-08-23 Automake 1.5
-
-A major and long-awaited release, that comes more than two years after
-1.4. It brings many changes, among which:
-@itemize
-@item The new dependency tracking scheme that uses @command{depcomp}.
-Aside from the improvement on the dependency tracking itself
-(@pxref{Dependency Tracking Evolution}), this also streamlines the use
-of @command{automake}-generated @file{Makefile.in}s as the @file{Makefile.in}s
-used during development are now the same as those used in
-distributions. Before that the @file{Makefile.in}s generated for
-maintainers required GNU @command{make} and GCC, they were different
-from the portable @file{Makefile} generated for distribution; this was
-causing some confusion.
-
-@item Support for per-target compilation flags.
-
-@item Support for reference to files in subdirectories in most
-@file{Makefile.am} variables.
-
-@item Introduction of the @code{dist_}, @code{nodist_}, and @code{nobase_}
-prefixes.
-@item Perl 4 support is finally dropped.
-@end itemize
-
-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
-@command{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, @samp{make distcheck} was
-improved to check that @samp{make uninstall} did remove all the files
-@samp{make install} installed, that @samp{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 @samp{+=} 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.
-
-@item 2002-03-05 Automake 1.6
-
-This release introduced versioned installation (@pxref{API
-Versioning}). This was mainly pushed by Havoc Pennington, taking the
-GNOME source tree as motive: due to incompatibilities between the
-autotools it's impossible for the GNOME packages to switch to Autoconf
-2.53 and Automake 1.5 all at once, so they are currently stuck with
-Autoconf 2.13 and Automake 1.4.
-
-The idea was to call this version @file{automake-1.6}, call all its
-bug-fix versions identically, and switch to @file{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.
-
-@item 2002-04-11 Automake 1.6.1
-
-1.6, and the upcoming 1.4-p6 release were the last release by Tom.
-This one and those following will be handled by Alexandre
-Duret-Lutz. Tom is still around, and will be there until about 1.7,
-but his interest into Automake is drifting away towards projects like
-@command{gcj}.
-
-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.
-
-@item 2002-06-14 Automake 1.6.2
-
-@item 2002-07-28 Automake 1.6.3
-@itemx 2002-07-28 Automake 1.4-p6
-
-Two releases on the same day. 1.6.3 is a bug-fix release.
-
-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.
-
-@item 2002-09-25 Automake 1.7
-
-This release switches to the new @file{configure.ac} scanner Akim
-was experimenting in 1.5.
-
-@item 2002-10-16 Automake 1.7.1
-@itemx 2002-12-06 Automake 1.7.2
-@itemx 2003-02-20 Automake 1.7.3
-@itemx 2003-04-23 Automake 1.7.4
-@itemx 2003-05-18 Automake 1.7.5
-@itemx 2003-07-10 Automake 1.7.6
-@itemx 2003-09-07 Automake 1.7.7
-@itemx 2003-10-07 Automake 1.7.8
-
-Many bug-fix releases. 1.7 lasted because the development version
-(upcoming 1.8) was suffering some major internal revamping.
-
-@item 2003-10-26 Automake on screen
-
-Episode 49, `Repercussions', in the third season of the `Alias' TV
-show is first aired.
-
-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 @file{Makefile.in} @code{generated by automake}...
-
-@item 2003-11-09 Automake 1.7.9
-
-@item 2003-12-10 Automake 1.8
-
-The most striking update is probably that of @command{aclocal}.
-
-@command{aclocal} now uses @code{m4_include} in the produced
-@file{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: @file{Makefile.in}
-must be rebuilt whenever a dependency of @file{configure} changes, but
-all the @file{m4} files included in @file{aclocal.m4} where unknown
-from @command{automake}. Now @command{automake} can just trace the
-@code{m4_include}s to discover the dependencies.
-
-@command{aclocal} also starts using the @option{--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
-@command{aclocal} versions, notably using handwritten
-@code{m4_include}s: @command{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.
-
-@itemx 2004-01-11 Automake 1.8.1
-@itemx 2004-01-12 Automake 1.8.2
-@itemx 2004-03-07 Automake 1.8.3
-@itemx 2004-04-25 Automake 1.8.4
-@itemx 2004-05-16 Automake 1.8.5
-
-@item 2004-07-28 Automake 1.9
-
-This release tries to simplify the compilation rules it outputs to
-reduce the size of the Makefile. The complaint initially come from
-the libgcj developers. Their @file{Makefile.in} generated with
-Automake 1.4 and custom build rules (1.4 did not support compiled
-Java) is 250KB@. The one generated by 1.8 was over 9MB@! 1.9 gets it
-down to 1.2MB@.
-
-Aside from this it contains mainly minor changes and bug-fixes.
-
-@itemx 2004-08-11 Automake 1.9.1
-@itemx 2004-09-19 Automake 1.9.2
-
-Automake has ten years. This chapter of the manual was initially
-written for this occasion.
-
-@itemx 2007-10-29 Automake repository moves to @code{savannah.gnu.org} and uses
-git as primary repository.
-
-@end table
-
-@node Dependency Tracking Evolution
-@section Dependency Tracking in Automake
-
-Over the years Automake has deployed three different dependency
-tracking methods. Each method, including the current one, has had
-flaws of various sorts. Here we lay out the different dependency
-tracking methods, their flaws, and their fixes. We conclude with
-recommendations for tool writers, and by indicating future directions
-for dependency tracking work in Automake.
-
-@menu
-* First Take on Dependencies:: Precomputed dependency tracking
-* Dependencies As Side Effects:: Update at developer compile time
-* Dependencies for the User:: Update at user compile time
-* Techniques for Dependencies:: Alternative approaches
-* Recommendations for Tool Writers:: What tool writers can do to help
-* Future Directions for Dependencies:: Languages Automake does not know
-@end menu
-
-@node First Take on Dependencies
-@subsection First Take on Dependency Tracking
-@unnumberedsubsubsec Description
-
-Our first attempt at automatic dependency tracking was based on the
-method recommended by GNU @command{make}. (@pxref{Automatic
-Prerequisites, , Generating Prerequisites Automatically, make, The GNU
-make Manual})
-
-This version worked by precomputing dependencies ahead of time. For
-each source file, it had a special @file{.P} file that held the
-dependencies. There was a rule to generate a @file{.P} file by
-invoking the compiler appropriately. All such @file{.P} files were
-included by the @file{Makefile}, thus implicitly becoming dependencies
-of @file{Makefile}.
-
-@unnumberedsubsubsec Bugs
-
-This approach had several critical bugs.
-
-@itemize
-@item
-The code to generate the @file{.P} file relied on @command{gcc}.
-(A limitation, not technically a bug.)
-@item
-The dependency tracking mechanism itself relied on GNU @command{make}.
-(A limitation, not technically a bug.)
-@item
-Because each @file{.P} file was a dependency of @file{Makefile}, this
-meant that dependency tracking was done eagerly by @command{make}.
-For instance, @samp{make clean} would cause all the dependency files
-to be updated, and then immediately removed. This eagerness also
-caused problems with some configurations; if a certain source file
-could not be compiled on a given architecture for some reason,
-dependency tracking would fail, aborting the entire build.
-@item
-As dependency tracking was done as a pre-pass, compile times were
-doubled--the compiler had to be run twice per source file.
-@item
-@samp{make dist} re-ran @command{automake} to generate a
-@file{Makefile} that did not have automatic dependency tracking (and
-that was thus portable to any version of @command{make}). In order to
-do this portably, Automake had to scan the dependency files and remove
-any reference that was to a source file not in the distribution.
-This process was error-prone. Also, if @samp{make dist} was run in an
-environment where some object file had a dependency on a source file
-that was only conditionally created, Automake would generate a
-@file{Makefile} that referred to a file that might not appear in the
-end user's build. A special, hacky mechanism was required to work
-around this.
-@end itemize
-
-@unnumberedsubsubsec Historical Note
-
-The code generated by Automake is often inspired by the
-@file{Makefile} style of a particular author. In the case of the first
-implementation of dependency tracking, I believe the impetus and
-inspiration was Jim Meyering. (I could be mistaken. If you know
-otherwise feel free to correct me.)
-
-@node Dependencies As Side Effects
-@subsection Dependencies As Side Effects
-@unnumberedsubsubsec Description
-
-The next refinement of Automake's automatic dependency tracking scheme
-was to implement dependencies as side effects of the compilation.
-This was aimed at solving the most commonly reported problems with the
-first approach. In particular we were most concerned with eliminating
-the weird rebuilding effect associated with make clean.
-
-In this approach, the @file{.P} files were included using the
-@code{-include} command, which let us create these files lazily. This
-avoided the @samp{make clean} problem.
-
-We only computed dependencies when a file was actually compiled. This
-avoided the performance penalty associated with scanning each file
-twice. It also let us avoid the other problems associated with the
-first, eager, implementation. For instance, dependencies would never
-be generated for a source file that was not compilable on a given
-architecture (because it in fact would never be compiled).
-
-@unnumberedsubsubsec Bugs
-
-@itemize
-@item
-This approach also relied on the existence of @command{gcc} and GNU
-@command{make}. (A limitation, not technically a bug.)
-@item
-Dependency tracking was still done by the developer, so the problems
-from the first implementation relating to massaging of dependencies by
-@samp{make dist} were still in effect.
-@item
-This implementation suffered from the ``deleted header file'' problem.
-Suppose a lazily-created @file{.P} file includes a dependency on a
-given header file, like this:
-
-@example
-maude.o: maude.c something.h
-@end example
-
-Now suppose that you remove @file{something.h} and update @file{maude.c}
-so that this include is no longer needed. If you run @command{make},
-you will get an error because there is no way to create
-@file{something.h}.
-
-We fixed this problem in a later release by further massaging the
-output of @command{gcc} to include a dummy dependency for each header
-file.
-@end itemize
-
-@node Dependencies for the User
-@subsection Dependencies for the User
-@unnumberedsubsubsec Description
-
-The bugs associated with @samp{make dist}, over time, became a real
-problem. Packages using Automake were being built on a large number
-of platforms, and were becoming increasingly complex. Broken
-dependencies were distributed in ``portable'' @file{Makefile.in}s,
-leading to user complaints. Also, the requirement for @command{gcc}
-and GNU @command{make} was a constant source of bug reports. The next
-implementation of dependency tracking aimed to remove these problems.
-
-We realized that the only truly reliable way to automatically track
-dependencies was to do it when the package itself was built. This
-meant discovering a method portable to any version of make and any
-compiler. Also, we wanted to preserve what we saw as the best point
-of the second implementation: dependency computation as a side effect
-of compilation.
-
-In the end we found that most modern make implementations support some
-form of include directive. Also, we wrote a wrapper script that let
-us abstract away differences between dependency tracking methods for
-compilers. For instance, some compilers cannot generate dependencies
-as a side effect of compilation. In this case we simply have the
-script run the compiler twice. Currently our wrapper script
-(@command{depcomp}) knows about twelve different compilers (including
-a "compiler" that simply invokes @command{makedepend} and then the
-real compiler, which is assumed to be a standard Unix-like C compiler
-with no way to do dependency tracking).
-
-@unnumberedsubsubsec Bugs
-
-@itemize
-@item
-Running a wrapper script for each compilation slows down the build.
-@item
-Many users don't really care about precise dependencies.
-@item
-This implementation, like every other automatic dependency tracking
-scheme in common use today (indeed, every one we've ever heard of),
-suffers from the ``duplicated new header'' bug.
-
-This bug occurs because dependency tracking tools, such as the
-compiler, only generate dependencies on the successful opening of a
-file, and not on every probe.
-
-Suppose for instance that the compiler searches three directories for
-a given header, and that the header is found in the third directory.
-If the programmer erroneously adds a header file with the same name to
-the first directory, then a clean rebuild from scratch could fail
-(suppose the new header file is buggy), whereas an incremental rebuild
-will succeed.
-
-What has happened here is that people have a misunderstanding of what
-a dependency is. Tool writers think a dependency encodes information
-about which files were read by the compiler. However, a dependency
-must actually encode information about what the compiler tried to do.
-
-This problem is not serious in practice. Programmers typically do not
-use the same name for a header file twice in a given project. (At
-least, not in C or C++. This problem may be more troublesome in
-Java.) This problem is easy to fix, by modifying dependency
-generators to record every probe, instead of every successful open.
-
-@item
-Since Automake generates dependencies as a side effect of compilation,
-there is a bootstrapping problem when header files are generated by
-running a program. The problem is that, the first time the build is
-done, there is no way by default to know that the headers are
-required, so make might try to run a compilation for which the headers
-have not yet been built.
-
-This was also a problem in the previous dependency tracking implementation.
-
-The current fix is to use @code{BUILT_SOURCES} to list built headers
-(@pxref{Sources}). This causes them to be built before any other
-build rules are run. This is unsatisfactory as a general solution,
-however in practice it seems sufficient for most actual programs.
-@end itemize
-
-This code is used since Automake 1.5.
-
-In GCC 3.0, we managed to convince the maintainers to add special
-command-line options to help Automake more efficiently do its job. We
-hoped this would let us avoid the use of a wrapper script when
-Automake's automatic dependency tracking was used with @command{gcc}.
-
-Unfortunately, this code doesn't quite do what we want. In
-particular, it removes the dependency file if the compilation fails;
-we'd prefer that it instead only touch the file in any way if the
-compilation succeeds.
-
-Nevertheless, since Automake 1.7, when a recent @command{gcc} is
-detected at @command{configure} time, we inline the
-dependency-generation code and do not use the @command{depcomp}
-wrapper script. This makes compilations faster for those using this
-compiler (probably our primary user base). The counterpart is that
-because we have to encode two compilation rules in @file{Makefile}
-(with or without @command{depcomp}), the produced @file{Makefile}s are
-larger.
-
-@node Techniques for Dependencies
-@subsection Techniques for Computing Dependencies
-
-There are actually several ways for a build tool like Automake to
-cause tools to generate dependencies.
-
-@table @asis
-@item @command{makedepend}
-This was a commonly-used method in the past. The idea is to run a
-special program over the source and have it generate dependency
-information. Traditional implementations of @command{makedepend} are
-not completely precise; ordinarily they were conservative and
-discovered too many dependencies.
-@item The tool
-An obvious way to generate dependencies is to simply write the tool so
-that it can generate the information needed by the build tool. This is
-also the most portable method. Many compilers have an option to
-generate dependencies. Unfortunately, not all tools provide such an
-option.
-@item The file system
-It is possible to write a special file system that tracks opens,
-reads, writes, etc, and then feed this information back to the build
-tool. @command{clearmake} does this. This is a very powerful
-technique, as it doesn't require cooperation from the
-tool. Unfortunately it is also very difficult to implement and also
-not practical in the general case.
-@item @code{LD_PRELOAD}
-Rather than use the file system, one could write a special library to
-intercept @code{open} and other syscalls. This technique is also quite
-powerful, but unfortunately it is not portable enough for use in
-@command{automake}.
-@end table
-
-@node Recommendations for Tool Writers
-@subsection Recommendations for Tool Writers
-
-We think that every compilation tool ought to be able to generate
-dependencies as a side effect of compilation. Furthermore, at least
-while @command{make}-based tools are nearly universally in use (at
-least in the free software community), the tool itself should generate
-dummy dependencies for header files, to avoid the deleted header file
-bug. Finally, the tool should generate a dependency for each probe,
-instead of each successful file open, in order to avoid the duplicated
-new header bug.
-
-@node Future Directions for Dependencies
-@subsection Future Directions for Dependencies
-
-Currently, only languages and compilers understood by Automake can
-have dependency tracking enabled. We would like to see if it is
-practical (and worthwhile) to let this support be extended by the user
-to languages unknown to Automake.
-
-@node Releases
-@section Release Statistics
-
-The following table (inspired by @samp{perlhist(1)}) quantifies the
-evolution of Automake using these metrics:
-
-@table @asis
-@item Date, Rel
-The date and version of the release.
-@item am
-The number of lines of the @command{automake} script.
-@item acl
-The number of lines of the @command{aclocal} script.
-@item pm
-The number of lines of the @command{Perl} supporting modules.
-@item @file{*.am}
-The number of lines of the @file{Makefile} fragments. The number in
-parentheses is the number of files.
-@item m4
-The number of lines (and files) of Autoconf macros.
-@item doc
-The number of pages of the documentation (the Postscript version).
-@item t
-The number of test cases in the test suite. Of those, the number in
-parentheses is the number of generated test cases.
-@end table
-
-@multitable {8888-88-88} {8.8-p8} {8888} {8888} {8888} {8888 (88)} {8888 (88)} {888} {888 (88)}
-@headitem Date @tab Rel @tab am @tab acl @tab pm @tab @file{*.am} @tab m4 @tab doc @tab t
-@item 1994-09-19 @tab CVS @tab 141 @tab @tab @tab 299 (24) @tab @tab @tab
-@item 1994-11-05 @tab CVS @tab 208 @tab @tab @tab 332 (28) @tab @tab @tab
-@item 1995-11-23 @tab 0.20 @tab 533 @tab @tab @tab 458 (35) @tab @tab 9 @tab
-@item 1995-11-26 @tab 0.21 @tab 613 @tab @tab @tab 480 (36) @tab @tab 11 @tab
-@item 1995-11-28 @tab 0.22 @tab 1116 @tab @tab @tab 539 (38) @tab @tab 12 @tab
-@item 1995-11-29 @tab 0.23 @tab 1240 @tab @tab @tab 541 (38) @tab @tab 12 @tab
-@item 1995-12-08 @tab 0.24 @tab 1462 @tab @tab @tab 504 (33) @tab @tab 14 @tab
-@item 1995-12-10 @tab 0.25 @tab 1513 @tab @tab @tab 511 (37) @tab @tab 15 @tab
-@item 1996-01-03 @tab 0.26 @tab 1706 @tab @tab @tab 438 (36) @tab @tab 16 @tab
-@item 1996-01-03 @tab 0.27 @tab 1706 @tab @tab @tab 438 (36) @tab @tab 16 @tab
-@item 1996-01-13 @tab 0.28 @tab 1964 @tab @tab @tab 934 (33) @tab @tab 16 @tab
-@item 1996-02-07 @tab 0.29 @tab 2299 @tab @tab @tab 936 (33) @tab @tab 17 @tab
-@item 1996-02-24 @tab 0.30 @tab 2544 @tab @tab @tab 919 (32) @tab 85 (1) @tab 20 @tab 9
-@item 1996-03-11 @tab 0.31 @tab 2877 @tab @tab @tab 919 (32) @tab 85 (1) @tab 29 @tab 17
-@item 1996-04-27 @tab 0.32 @tab 3058 @tab @tab @tab 921 (31) @tab 85 (1) @tab 30 @tab 26
-@item 1996-05-18 @tab 0.33 @tab 3110 @tab @tab @tab 926 (31) @tab 105 (1) @tab 30 @tab 35
-@item 1996-05-28 @tab 1.0 @tab 3134 @tab @tab @tab 973 (32) @tab 105 (1) @tab 30 @tab 38
-@item 1997-06-22 @tab 1.2 @tab 6089 @tab 385 @tab @tab 1294 (36) @tab 592 (20) @tab 37 @tab 126
-@item 1998-04-05 @tab 1.3 @tab 6415 @tab 422 @tab @tab 1470 (39) @tab 741 (23) @tab 39 @tab 156
-@item 1999-01-14 @tab 1.4 @tab 7240 @tab 426 @tab @tab 1591 (40) @tab 734 (20) @tab 51 @tab 197
-@item 2001-05-08 @tab 1.4-p1 @tab 7251 @tab 426 @tab @tab 1591 (40) @tab 734 (20) @tab 51 @tab 197
-@item 2001-05-24 @tab 1.4-p2 @tab 7268 @tab 439 @tab @tab 1591 (40) @tab 734 (20) @tab 49 @tab 197
-@item 2001-06-07 @tab 1.4-p3 @tab 7312 @tab 439 @tab @tab 1591 (40) @tab 734 (20) @tab 49 @tab 197
-@item 2001-06-10 @tab 1.4-p4 @tab 7321 @tab 439 @tab @tab 1591 (40) @tab 734 (20) @tab 49 @tab 198
-@item 2001-07-15 @tab 1.4-p5 @tab 7228 @tab 426 @tab @tab 1596 (40) @tab 734 (20) @tab 51 @tab 198
-@item 2001-08-23 @tab 1.5 @tab 8016 @tab 475 @tab 600 @tab 2654 (39) @tab 1166 (29) @tab 63 @tab 327
-@item 2002-03-05 @tab 1.6 @tab 8465 @tab 475 @tab 1136 @tab 2732 (39) @tab 1603 (27) @tab 66 @tab 365
-@item 2002-04-11 @tab 1.6.1 @tab 8544 @tab 475 @tab 1136 @tab 2741 (39) @tab 1603 (27) @tab 66 @tab 372
-@item 2002-06-14 @tab 1.6.2 @tab 8575 @tab 475 @tab 1136 @tab 2800 (39) @tab 1609 (27) @tab 67 @tab 386
-@item 2002-07-28 @tab 1.6.3 @tab 8600 @tab 475 @tab 1153 @tab 2809 (39) @tab 1609 (27) @tab 67 @tab 391
-@item 2002-07-28 @tab 1.4-p6 @tab 7332 @tab 455 @tab @tab 1596 (40) @tab 735 (20) @tab 49 @tab 197
-@item 2002-09-25 @tab 1.7 @tab 9189 @tab 471 @tab 1790 @tab 2965 (39) @tab 1606 (28) @tab 73 @tab 430
-@item 2002-10-16 @tab 1.7.1 @tab 9229 @tab 475 @tab 1790 @tab 2977 (39) @tab 1606 (28) @tab 73 @tab 437
-@item 2002-12-06 @tab 1.7.2 @tab 9334 @tab 475 @tab 1790 @tab 2988 (39) @tab 1606 (28) @tab 77 @tab 445
-@item 2003-02-20 @tab 1.7.3 @tab 9389 @tab 475 @tab 1790 @tab 3023 (39) @tab 1651 (29) @tab 84 @tab 448
-@item 2003-04-23 @tab 1.7.4 @tab 9429 @tab 475 @tab 1790 @tab 3031 (39) @tab 1644 (29) @tab 85 @tab 458
-@item 2003-05-18 @tab 1.7.5 @tab 9429 @tab 475 @tab 1790 @tab 3033 (39) @tab 1645 (29) @tab 85 @tab 459
-@item 2003-07-10 @tab 1.7.6 @tab 9442 @tab 475 @tab 1790 @tab 3033 (39) @tab 1660 (29) @tab 85 @tab 461
-@item 2003-09-07 @tab 1.7.7 @tab 9443 @tab 475 @tab 1790 @tab 3041 (39) @tab 1660 (29) @tab 90 @tab 467
-@item 2003-10-07 @tab 1.7.8 @tab 9444 @tab 475 @tab 1790 @tab 3041 (39) @tab 1660 (29) @tab 90 @tab 468
-@item 2003-11-09 @tab 1.7.9 @tab 9444 @tab 475 @tab 1790 @tab 3048 (39) @tab 1660 (29) @tab 90 @tab 468
-@item 2003-12-10 @tab 1.8 @tab 7171 @tab 585 @tab 7730 @tab 3236 (39) @tab 1666 (31) @tab 104 @tab 521
-@item 2004-01-11 @tab 1.8.1 @tab 7217 @tab 663 @tab 7726 @tab 3287 (39) @tab 1686 (31) @tab 104 @tab 525
-@item 2004-01-12 @tab 1.8.2 @tab 7217 @tab 663 @tab 7726 @tab 3288 (39) @tab 1686 (31) @tab 104 @tab 526
-@item 2004-03-07 @tab 1.8.3 @tab 7214 @tab 686 @tab 7735 @tab 3303 (39) @tab 1695 (31) @tab 111 @tab 530
-@item 2004-04-25 @tab 1.8.4 @tab 7214 @tab 686 @tab 7736 @tab 3310 (39) @tab 1701 (31) @tab 112 @tab 531
-@item 2004-05-16 @tab 1.8.5 @tab 7240 @tab 686 @tab 7736 @tab 3299 (39) @tab 1701 (31) @tab 112 @tab 533
-@item 2004-07-28 @tab 1.9 @tab 7508 @tab 715 @tab 7794 @tab 3352 (40) @tab 1812 (32) @tab 115 @tab 551
-@item 2004-08-11 @tab 1.9.1 @tab 7512 @tab 715 @tab 7794 @tab 3354 (40) @tab 1812 (32) @tab 115 @tab 552
-@item 2004-09-19 @tab 1.9.2 @tab 7512 @tab 715 @tab 7794 @tab 3354 (40) @tab 1812 (32) @tab 132 @tab 554
-@item 2004-11-01 @tab 1.9.3 @tab 7507 @tab 718 @tab 7804 @tab 3354 (40) @tab 1812 (32) @tab 134 @tab 556
-@item 2004-12-18 @tab 1.9.4 @tab 7508 @tab 718 @tab 7856 @tab 3361 (40) @tab 1811 (32) @tab 140 @tab 560
-@item 2005-02-13 @tab 1.9.5 @tab 7523 @tab 719 @tab 7859 @tab 3373 (40) @tab 1453 (32) @tab 142 @tab 562
-@item 2005-07-10 @tab 1.9.6 @tab 7539 @tab 699 @tab 7867 @tab 3400 (40) @tab 1453 (32) @tab 144 @tab 570
-@item 2006-10-15 @tab 1.10 @tab 7859 @tab 1072 @tab 8024 @tab 3512 (40) @tab 1496 (34) @tab 172 @tab 604
-@item 2008-01-19 @tab 1.10.1 @tab 7870 @tab 1089 @tab 8025 @tab 3520 (40) @tab 1499 (34) @tab 173 @tab 617
-@item 2008-11-23 @tab 1.10.2 @tab 7882 @tab 1089 @tab 8027 @tab 3540 (40) @tab 1509 (34) @tab 176 @tab 628
-@item 2009-05-17 @tab 1.11 @tab 8721 @tab 1092 @tab 8289 @tab 4164 (42) @tab 1714 (37) @tab 181 @tab 732 (20)
-@end multitable
-
-
@c ========================================================== Appendices
@page