-ChangeLog merge=merge-changelog
+NEWS merge=union
*.texi* diff=texinfo
/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
@code{CTAGSFLAGS} can be used by the user to pass additional flags,
and @code{AM_CTAGSFLAGS} can be used by the @file{Makefile.am}.
+@trindex id
Automake will also generate an @code{ID} rule that will run
@command{mkid} on the source. This is only supported on a
directory-by-directory basis.
-@trindex id
Similarly, the @code{cscope} rule will create a list of all the source
files in the tree and run @command{cscope} to build an inverted index
(by default @command{cscope}); @code{CSCOPEFLAGS} and
@code{CSCOPE_ARGS} can be used by the user to pass additional flags and
file names respectively, while @code{AM_CSCOPEFLAGS} can be used by the
-@file{Makefile.am}.
+@file{Makefile.am}. Note that, currently, the Automake-provided
+@code{cscope} support, when used in a VPATH build, might not work well
+with non-GNU make implementations (especially with make implementations
+performing @ref{Automatic Rule Rewriting, , VPATH rewrites, autoconf,
+The Autoconf Manual}).
Finally, Automake also emits rules to support the
@uref{http://www.gnu.org/software/global/, GNU Global Tags program}.
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
## (among them, TAP).
# Restructured Text title and section.
-am__rst_title = sed 's/.*/ & /;h;s/./=/g;p;x;p;g;p;s/.*//'
-am__rst_section = sed 'p;s/./=/g;p;g'
+am__rst_title = { sed 's/.*/ & /;h;s/./=/g;p;x;s/ *$$//;p;g' && echo; }
+am__rst_section = { sed 'p;s/./=/g;' && echo; }
# Solaris 10 'make', and several other traditional 'make' implementations,
# pass "-e" to $(SHELL), and POSIX 2008 even requires this. Work around it
## and are thus executed also with "make -n" -- either because they
## are declared as dependencies to '.MAKE' (NetBSD make), or because
## their recipes contain the "$(MAKE)" string (GNU and Solari make).
+
+## The case statement has [:] in order to not tickle makefile-deps.test
+## which greps for '^ *:'.
am__make_dryrun = \
{ \
am__dry=no; \
for am__flg in : $(MAKEFLAGS); do \
case $$am__flg in \
- :) ;; \
+ [:]) ;; \
*=*|--*) ;; \
*n*) am__dry=yes; break;; \
esac; \
--- /dev/null
+#! /bin/sh
+# Copyright (C) 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test cscope functionality.
+
+. ./defs || Exit 1
+
+plan_ 18
+
+ocwd=`pwd` || fatal_ "getting top-level directory"
+
+cat >> configure.in << 'END'
+AC_CONFIG_FILES([sub/Makefile])
+AC_SUBST([CC], [who-cares])
+AC_SUBST([CXX], [who-cares])
+AC_SUBST([FC], [who-cares])
+AC_SUBST([GCJ], [who-cares])
+AM_PATH_LISPDIR
+AC_OUTPUT
+END
+
+mkdir sub sub/subsub
+
+cat > Makefile.am <<'END'
+SUBDIRS = sub
+bin_PROGRAMS = foo
+foo_SOURCES = foo.c bar.cpp baz.f90
+lisp_LISP = foo.el
+EXTRA_DIST = foo.el
+END
+
+cat > sub/Makefile.am <<'END'
+bin_PROGRAMS = bar
+bar_SOURCES = subsub/dist.c
+nodist_bar_SOURCES = subsub/gen.c
+subsub/gen.c:
+ $(MKDIR_P) subsub
+ echo 'int generated_subsub () { return 0; }' > $@
+CLEANFILES = subsub/gen.c
+END
+
+echo 'int foo_func () { return 0; }' > foo.c
+echo 'int main () { return 0; }' > bar.cpp
+cat > baz.f90 <<'END'
+ subroutine baz
+ end
+END
+: > foo.el
+echo 'int main () { return 0; }' > sub/subsub/dist.c
+
+$ACLOCAL || fatal_ "aclocal failed"
+$AUTOCONF || fatal_ "autoconf failed"
+$AUTOMAKE -i -a || fatal_ "automake -i -a failed"
+
+# Sun cscope is interactive without redirection.
+if cscope --version </dev/null; then
+ have_cscope=yes
+else
+ have_cscope=no
+fi
+
+test_cleanup ()
+{
+ r=ok
+ if test -f configure; then
+ # In-tree build.
+ $MAKE distclean
+ else
+ # VPATH build.
+ $MAKE distcleancheck
+ fi \
+ && test ! -f cscope.files \
+ && test ! -f cscope.out \
+ && test ! -f cscope.in.out \
+ && test ! -f cscope.po.out \
+ || r='not ok'
+ result_ "$r" "[$pfx] make distcheck"
+}
+
+test_cscope ()
+{
+ r=ok
+ $MAKE -n cscope || r='not ok'
+ result_ "$r" "[$pfx] make -n cscope"
+
+ if test $have_cscope = no; then
+ # For later tests.
+ touch cscope.files cscope.out cscope.in.out cscope.po.out
+ skip_row_ 3 -r "no cscope program avaiable"
+ return 0
+ fi
+
+ r=ok
+ $MAKE cscope 2>stderr || r='not ok'
+ cat stderr >&2
+ grep 'cannot find file' stderr && r='not ok'
+ rm -f stderr
+ result_ "$r" "[$pfx] make cscope"
+
+ r=ok
+ test -f cscope.files \
+ && $FGREP foo.c cscope.files \
+ && $FGREP bar.cpp cscope.files \
+ && $FGREP sub/subsub/dist.c cscope.files \
+ && $FGREP sub/subsub/gen.c cscope.files \
+ || r='not ok'
+ result_ "$r" "[$pfx] cscope.files looks correct"
+
+ r=ok
+ # cscope.files might not exist of the earlier "make cscope" failed.
+ cp cscope.files cscope.files1 \
+ && $MAKE cscope \
+ && diff cscope.files cscope.files1 \
+ || r='not ok'
+ rm -f cscope.files1
+ result_ "$r" "[$pfx] second \"make cscope\" is consistent"
+}
+
+my_configure ()
+{
+ command_ok_ "[$pfx] configure" \
+ "$1"/configure EMACS=no --with-lispdir=/who/cares
+}
+
+if using_gmake; then
+
+ cd "$ocwd"
+ pfx="relative VPATH"
+ mkdir build
+ cd build
+ my_configure ..
+ test_cscope
+ test_cleanup
+
+ cd "$ocwd"
+ pfx="absolute VPATH"
+ mkdir build2
+ cd build2
+ my_configure "$ocwd"
+ test_cscope
+ test_cleanup
+
+else
+
+ skip_row_ 12 -r "cscope in VPATH required GNU make"
+
+fi
+
+cd "$ocwd"
+pfx="in-tree build"
+my_configure .
+test_cscope
+test_cleanup
+
+:
+++ /dev/null
-#! /bin/sh
-# Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see <http://www.gnu.org/licenses/>.
-
-# Test cscope functionality.
-
-required=
-. ./defs || Exit 1
-
-cat >> configure.in << 'END'
-AC_CONFIG_FILES([sub/Makefile])
-AC_PROG_CC
-AC_PROG_CXX
-AC_PROG_FC
-AM_PROG_GCJ
-AM_PATH_LISPDIR
-AC_OUTPUT
-END
-
-mkdir sub sub/subsub
-
-cat >Makefile.am <<'END'
-SUBDIRS = sub
-bin_PROGRAMS = foo
-foo_SOURCES = foo.c bar.cpp baz.f90
-lisp_LISP = foo.el
-EXTRA_DIST = foo.el
-END
-
-cat >sub/Makefile.am <<'END'
-bin_PROGRAMS = bar
-bar_SOURCES = subsub/dist.c
-nodist_bar_SOURCES = subsub/gen.c
-subsub/gen.c:
- $(MKDIR_P) subsub
- echo 'int generated_subsub () { return 0; }' > $@
-CLEANFILES = subsub/gen.c
-END
-
-echo 'int foo_func () { return 0; }' > foo.c
-echo 'int main () { return 0; }' > bar.cpp
-cat > baz.f90 <<'END'
- subroutine baz
- end
-END
-: >foo.el
-echo 'int main () { return 0; }' > sub/subsub/dist.c
-
-$ACLOCAL
-$AUTOCONF
-$AUTOMAKE --add-missing
-
-mkdir build
-cd build
-../configure || Exit 77
-
-$MAKE -n cscope
-
-: ${CSCOPE=cscope}
-( $CSCOPE --version ) >/dev/null 2>&1 || Exit 77
-
-$MAKE cscope 2>stderr || { cat stderr >&2; Exit 1; }
-cat stderr >&2
-grep 'cannot find file' stderr && Exit 1
-
-test -f cscope.files
-$FGREP foo.c cscope.files
-$FGREP bar.cpp cscope.files
-$FGREP sub/subsub/dist.c cscope.files
-$FGREP sub/subsub/gen.c cscope.files
-
-cp cscope.files cscope.files1
-$MAKE cscope
-diff cscope.files cscope.files1
-
-$MAKE distclean
-test ! -f cscope.files
-test ! -f cscope.out
-test ! -f cscope.in.out
-test ! -f cscope.po.out
-
-
-`pwd`/../configure || Exit 77
-
-$MAKE cscope 2>stderr || { cat stderr >&2; Exit 1; }
-cat stderr >&2
-grep 'cannot find file' stderr && Exit 1
-$MAKE || Exit 77
-$MAKE distclean
-
-cd ..
-./configure
-$MAKE distcheck
-
-:
yes)
po=Plo objext=lo a=la
normalized_target=libfoo_la
- LIBPRIMARY=LTLIBRARIES LINKADD=LIBADD
+ # On platforms requiring that no undefined symbols exist in order
+ # to build shared libraries (e.g. Windows DLLs), you have to
+ # explicitly declare that the libtool library you are building
+ # does not actually have any undefined symbols, for libtool to
+ # even try to build it as a shared library. Without that
+ # explicit declaration, libtool falls back to a static library
+ # only, regardless of any --enable-shared flags etc.
+ LIBPRIMARY=LTLIBRARIES LINKADD=LIBADD NOUNDEF=-no-undefined
+ libbaz_ldflags="libbaz_${a}_LDFLAGS = $NOUNDEF"
echo lib_LTLIBRARIES = libfoo.la >> Makefile.am
make_ok ()
{
no)
po=Po objext='$(OBJEXT)' a=a
normalized_target=foo
- LIBPRIMARY=LIBRARIES LINKADD=LDADD
+ LIBPRIMARY=LIBRARIES LINKADD=LDADD NOUNDEF=
+ libbaz_ldflags=
echo bin_PROGRAMS = foo >> Makefile.am
make_ok ()
{
# We include subfoo only to be sure that the munging in depcomp
# doesn't remove too much from the object file name.
${normalized_target}_SOURCES = foo.c sub/subfoo.c foo.h sub/subfoo.h
+${normalized_target}_LDFLAGS = $NOUNDEF
${normalized_target}_${LINKADD} = src/libbaz.$a
.PHONY: grep-test
# We include sub2foo only to be sure that the munging in depcomp
# doesn't remove too much from the object file name.
libbaz_${a}_SOURCES = baz.c sub2/sub2foo.c baz.h sub2/sub2foo.h
+$libbaz_ldflags
END
cat > foo.c <<'END'
case $depmode in
auto)
- plan_ 84
- do_all_tests ()
- {
- do_test default
- do_test noshared --disable-shared
- do_test nostatic --disable-static
- }
+ if test $depcomp_with_libtool = no; then
+ plan_ 28
+ do_all_tests () { do_test; }
+ else
+ plan_ 84
+ do_all_tests ()
+ {
+ do_test default
+ do_test noshared --disable-shared
+ do_test nostatic --disable-static
+ }
+ fi
displayed_depmode='..*' # At least one character long.
cfg_deptrack=--enable-dependency-tracking ;;
disabled)
plan_ 28
- do_all_tests() { do_test; }
+ do_all_tests () { do_test; }
displayed_depmode=none
cfg_deptrack=--disable-dependency-tracking ;;
*)
plan_ 28
- do_all_tests() { do_test; }
+ do_all_tests () { do_test; }
displayed_depmode="(cached) $depmode"
cfg_deptrack="$cachevar=$depmode"
# Sanity check: ensure the cache variable we force is truly
case $c in
# Assume gzip(1) is available on every reasonable portability target.
gzip)
- continue;;
+ continue
+ ;;
# On Cygwin, as of 9/2/2012, 'compress' is provided by sharutils
# and is just a dummy script that is not able to actually compress
# (it can only decompress). So, check that the 'compress' program
compress)
for x in 1 2 3 4 5 6 7 8; do
echo aaaaaaaaaaaaaaa
- done | $c -c >/dev/null && continue;;
+ done | $c -c >/dev/null && continue
+ : For shells with busted 'set -e'.
+ ;;
*)
- $c --version </dev/null >&2 && continue;;
+ $c --version </dev/null >&2 && continue
+ : For shells with busted 'set -e'.
+ ;;
esac
echo $c
done | tr "$nl" ' '`
confvar.test \
confvar2.test \
copy.test \
-cscope.test \
+cscope.tap \
cscope2.test \
cscope3.test \
cxx.test \
reqd.test \
reqd2.test \
repeated-options.test \
+rst-formatting.test \
rulepat.test \
self-check-cleanup.tap \
self-check-configure-help.test \
[AC_LANG_PROGRAM([[#include <unistd.h>]],
[[write (9, "foobar\n", 7); return 0;]])],
[AM_RUN_LOG([./conftest$EXEEXT 9>&1]) \
- && AM_RUN_LOG([(./conftest$EXEEXT 9>&1) | grep "^foobar"]) \
+dnl Leading ":;" required to avoid having two nested subshells starting
+dnl with '((' in the generated configure: that is unportable and could
+dnl confuse some shells (e.g., NetBSD 5.1 /bin/ksh) into thinking we are
+dnl trying to perform an arithmetic operation.
+ && AM_RUN_LOG([:; (./conftest$EXEEXT 9>&1) | grep "^foobar"]) \
&& am__ok=yes])
test $am__ok = yes || AS_EXIT([63])
AM_CONDITIONAL([real_EXEEXT], [test -n "$EXEEXT"])
--- /dev/null
+#! /bin/sh
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Parallel testsuite harness: check APIs for the registering the
+# "global test result" in `*.trs' files, as documented in the automake
+# manual.
+
+am_create_testdir=empty
+. ./defs || Exit 1
+
+sed -n '/^am__rst_[a-z_][a-z_]* =/p' "$am_amdir"/check.am > Makefile \
+ || framework_failure_ "fetching definitions from check.am"
+
+cat >> Makefile << 'END'
+test:
+ printf '%s\n' "$$in" | $(am__rst_title) > title-got
+ printf '%s\n' "$$in" | $(am__rst_section) > section-got
+ cat title-exp
+ cat title-got
+ diff title-exp title-got
+ cat section-exp
+ cat section-got
+ diff section-exp section-got
+END
+
+# -------------------------------------------------------------------------
+
+cat > title-exp <<'END'
+==============
+ ab cd ef
+==============
+
+END
+
+cat > section-exp <<'END'
+ab cd ef
+========
+
+END
+
+env in='ab cd ef' $MAKE test
+
+# -------------------------------------------------------------------------
+
+cat > title-exp <<'END'
+============================================================================
+ 0123456789012345678901234567890123456789012345678901234567890123456789
+============================================================================
+
+END
+
+cat > section-exp <<'END'
+0123456789012345678901234567890123456789012345678901234567890123456789
+======================================================================
+
+END
+
+in=0123456789012345678901234567890123456789012345678901234567890123456789
+env in=$in $MAKE test
+
+# -------------------------------------------------------------------------
+
+cat > title-exp <<'END'
+=======
+ x
+=======
+
+END
+
+cat > section-exp <<'END'
+x
+=
+
+END
+
+env in=x $MAKE test
+
+# -------------------------------------------------------------------------
+
+:
esac
}
-command_ok_ '"make check" fails' eval 'not $MAKE check >stdout'
+command_ok_ '"make check" fails' eval '
+ (
+ st=0; $MAKE check >stdout || st=$?
+ # Extra "echo" and silencing of xtraces required to avoid possible
+ # garbled output with NetBSD make, which would miss some final
+ # newlines in the expected places and thus mess up our TAP output.
+ set +x; echo
+ test $st -gt 0
+ )
+'
cat stdout # For debugging.
command_ok_ "count of test results" count_test_results \
#! /bin/sh
-# Copyright (C) 2011 Free Software Foundation, Inc.
+# Copyright (C) 2011, 2012 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# - `test-driver' script not correctly distributed when TESTS is
# defined in a subdir Makefile
+am_create_testdir=empty
am_parallel_tests=yes
. ./defs || Exit 1
-cat >> configure.in << 'END'
-AC_CONFIG_FILES([tests/Makefile])
-AC_OUTPUT
+ocwd=`pwd` || fatal_ "getting current working directory"
+
+do_check ()
+{
+ whereopts=$1 auxdir=$2
+ case $#,$whereopts in
+ 2,ac) ac_opts=parallel-tests am_code= ;;
+ 2,am) am_opts=parallel-tests ac_code= ;;
+ *) fatal_ "do_check: bad usage";;
+ esac
+ mkdir $whereopts
+ cd $whereopts
+ mkdir tests
+ unindent > configure.in << END
+ AC_INIT([$me], [1.0])
+ AC_CONFIG_AUX_DIR([$auxdir])
+ AM_INIT_AUTOMAKE([$ac_opts])
+ AC_CONFIG_FILES([Makefile tests/Makefile])
+ AC_OUTPUT
END
-
-rm -f depcomp # It's unneeded.
-
-mkdir tests
-
-cat > Makefile.am << 'END'
-SUBDIRS = tests
-check-local: test-top
-test-top: distdir
- ls -l $(distdir) $(distdir)/* ;: For debugging.
- test -f $(distdir)/test-driver
-.PHONY: test-top
+ if test $auxdir = .; then
+ test_driver=test-driver
+ else
+ mkdir $auxdir
+ test_driver=$auxdir/test-driver
+ fi
+ # No 'AUTOMAKE_OPTIONS' in here -- purposely.
+ unindent > Makefile.am << END
+ SUBDIRS = tests
+ check-local: test-top
+ test-top: distdir
+ ls -l \$(distdir) \$(distdir)/* ;: For debugging.
+ test -f \$(distdir)/$test_driver
+ .PHONY: test-top
END
-
-cat > tests/Makefile.am << 'END'
-check-local: test-sub
-test-sub:
- echo ' ' $(DIST_COMMON) ' ' | grep '[ /]test-driver '
-TESTS = foo.test
-EXTRA_DIST = $(TESTS)
+ unindent > tests/Makefile.am << END
+ AUTOMAKE_OPTIONS = $am_opts
+ check-local: test-sub
+ test-sub:
+ echo ' ' \$(DIST_COMMON) ' ' | grep '[ /]$test_driver '
+ TESTS = foo.test
+ EXTRA_DIST = \$(TESTS)
END
-
-cat > tests/foo.test << 'END'
-#!/bin/sh
-exit 0
+ unindent > tests/foo.test << 'END'
+ #!/bin/sh
+ exit 0
END
-chmod a+x tests/foo.test
-
-$ACLOCAL
-$AUTOCONF
-$AUTOMAKE -a
-./configure
-$MAKE test-top
-cd tests; $MAKE test-sub; cd ..;
-$MAKE distcheck
-
-# Try again, with a `config_auxdir' != `.' this time.
-
-$MAKE distclean
-
-mkdir build-aux
-mv missing install-sh test-driver build-aux
-
-for d in . tests; do
- sed 's|test-driver|build-aux/test-driver|' $d/Makefile.am > $d/t
- mv -f $d/t $d/Makefile.am
- cat $d/Makefile.am # For debugging.
-done
-
-# Extra newline possibly required by OpenBSD 3.9 sed, see the autoconf
-# manual for details.
-sed '/^AC_INIT/i\
-AC_CONFIG_AUX_DIR([build-aux])
-' configure.in > t
-mv -f t configure.in
-cat configure.in # For debugging.
-
-touch aclocal.m4 # To avoid useless remakes.
-$AUTOCONF
-$AUTOMAKE
-./configure
-$MAKE test-top
-cd tests; $MAKE test-sub; cd ..;
-$MAKE distcheck
+ chmod a+x tests/foo.test
+ $ACLOCAL
+ $AUTOCONF
+ $AUTOMAKE -a
+ ./configure
+ $MAKE test-top
+ cd tests
+ $MAKE test-sub
+ cd ..
+ $MAKE distcheck
+ # Try code path without automatic installation of required files.
+ mv -f Makefile.in Makefile.sav
+ mv -f tests/Makefile.in tests/Makefile.sav
+ $AUTOMAKE
+ diff Makefile.in Makefile.sav
+ diff tests/Makefile.in tests/Makefile.sav
+ :
+}
+
+do_check ac .
+do_check am build-aux
:
projects / platform / upstream / automake.git / commitdiff