This is automake-history.info, produced by makeinfo version 5.2 from
automake-history.texi.

This manual describes (part of) the history of GNU Automake, a program
that creates GNU standards-compliant Makefiles from template files.

   Copyright (C) 1995-2013 Free Software Foundation, Inc.

     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."


File: automake-history.info,  Node: Top,  Next: Timeline,  Up: (dir)

Brief History of Automake
*************************

This manual describes (part of) the history of GNU Automake, a program
that creates GNU standards-compliant Makefiles from template files.

   Copyright (C) 1995-2013 Free Software Foundation, Inc.

     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."

* 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

 -- 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



File: automake-history.info,  Node: Timeline,  Next: Dependency Tracking Evolution,  Prev: Top,  Up: Top

1 Timeline
**********

1994-09-19 First CVS commit.

     If we can trust the CVS repository, David J. MacKenzie (djm)
     started working on Automake (or AutoMake, as it was spelt then)
     this Monday.

     The first version of the 'automake' script looks as follows.

          #!/bin/sh

          status=0

          for makefile
          do
            if test ! -f ${makefile}.am; then
              echo "automake: ${makefile}.am: No such honkin' file"
              status=1
              continue
            fi

            exec 4> ${makefile}.in

          done

     From this you can already see that Automake will be about reading
     '*.am' file and producing '*.in' files.  You cannot see anything
     else, but if you also know that David is the one who created
     Autoconf two years before you can guess the rest.

     Several commits follow, and by the end of the day Automake is
     reported to work for GNU fileutils and GNU m4.

     The modus operandi is the one that is still used today: variable
     assignments in 'Makefile.am' files trigger injections of precanned
     'Makefile' fragments into the generated 'Makefile.in'.  The use of
     'Makefile' fragments was inspired by the 4.4BSD 'make' and include
     files, however Automake aims to be portable and to conform to the
     GNU standards for 'Makefile' variables and targets.

     At this point, the most recent release of Autoconf is version 1.11,
     and David is preparing to release Autoconf 2.0 in late October.  As
     a matter of fact, he will barely touch Automake after September.

1994-11-05 David MacKenzie's last commit.

     At this point Automake is a 200 line portable shell script, plus
     332 lines of 'Makefile' fragments.  In the 'README', David states
     his ambivalence between "portable shell" and "more appropriate
     language":

          I wrote it keeping in mind the possibility of it becoming an
          Autoconf macro, so it would run at configure-time.  That would
          slow configuration down a bit, but allow users to modify the
          Makefile.am without needing to fetch the AutoMake package.
          And, the Makefile.in files wouldn't need to be distributed.
          But all of AutoMake would.  So I might reimplement AutoMake in
          Perl, m4, or some other more appropriate language.

     Automake is described as "an experimental Makefile generator".
     There is no documentation.  Adventurous users are referred to the
     examples and patches needed to use Automake with GNU m4 1.3,
     fileutils 3.9, time 1.6, and development versions of find and
     indent.

     These examples seem to have been lost.  However at the time of
     writing (10 years later in September, 2004) the FSF still
     distributes a package that uses this version of Automake: check out
     GNU termutils 2.0.

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 'Makefile.in' up to GNU standards.
     This was hard, and one day he saw Automake on
     <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 Franc,ois Pinard knew, who were all interested in making a
     common infrastructure for GNU projects, and shared a similar
     outlook on how to do it.  So they were able to make some progress.
     It came along with Autoconf and extensions thereof, and then
     Automake from David and Tom (who were both gnitsians).  One of
     their ideas was to write a document paralleling the GNU standards,
     that was more strict in some ways and more detailed.  They never
     finished the GNITS standards, but the ideas mostly made their way
     into Automake.

1995-11-23 Automake 0.20

     Besides introducing automatic dependency tracking (*note Dependency
     Tracking Evolution::), this version also supplies a 9-page manual.

     At this time 'aclocal' and 'AM_INIT_AUTOMAKE' did not exist, so
     many things had to be done by hand.  For instance, here is what a
     configure.in (this is the former name of the 'configure.ac' we use
     today) must contain in order to use Automake 0.20:

          PACKAGE=cpio
          VERSION=2.3.911
          AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE")
          AC_DEFINE_UNQUOTED(VERSION, "$VERSION")
          AC_SUBST(PACKAGE)
          AC_SUBST(VERSION)
          AC_ARG_PROGRAM
          AC_PROG_INSTALL

     (Today all of the above is achieved by 'AC_INIT' and
     'AM_INIT_AUTOMAKE'.)

     Here is how programs are specified in 'Makefile.am':

          PROGRAMS = hello
          hello_SOURCES = hello.c

     This looks pretty much like what we do today, except the 'PROGRAMS'
     variable has no directory prefix specifying where 'hello' should be
     installed: all programs are installed in '$(bindir)'.
     'LIBPROGRAMS' can be used to specify programs that must be built
     but not installed (it is called 'noinst_PROGRAMS' nowadays).

     Programs can be built conditionally using 'AC_SUBST'itutions:

          PROGRAMS = @progs@
          AM_PROGRAMS = foo bar baz

     ('AM_PROGRAMS' has since then been renamed to 'EXTRA_PROGRAMS'.)

     Similarly scripts, static libraries, and data can be built and
     installed using the 'LIBRARIES', 'SCRIPTS', and 'DATA' variables.
     However 'LIBRARIES' were treated a bit specially in that Automake
     did automatically supply the 'lib' and '.a' prefixes.  Therefore to
     build 'libcpio.a', one had to write

          LIBRARIES = cpio
          cpio_SOURCES = ...

     Extra files to distribute must be listed in 'DIST_OTHER' (the
     ancestor of 'EXTRA_DIST').  Also extra directories that are to be
     distributed should appear in 'DIST_SUBDIRS', but the manual
     describes this as a temporary ugly hack (today extra directories
     should also be listed in 'EXTRA_DIST', and 'DIST_SUBDIRS' is used
     for another purpose, *note Conditional Subdirectories:
     (automake)Conditional Subdirectories.).

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
     'my' variables (only dynamically scoped 'local' variables), without
     function prototypes, with function calls that needs to be prefixed
     with '&', etc.  Traces of this old style can still be found in
     today's 'automake'.

1995-11-28 Automake 0.22
1995-11-29 Automake 0.23

     Bug fixes.

1995-12-08 Automake 0.24
1995-12-10 Automake 0.25

     Releases are raining.  0.24 introduces the uniform naming scheme we
     use today, i.e., 'bin_PROGRAMS' instead of 'PROGRAMS',
     'noinst_LIBRARIES' instead of 'LIBLIBRARIES', etc.  (However
     'EXTRA_PROGRAMS' does not exist yet, 'AM_PROGRAMS' is still in use;
     and 'TEXINFOS' and 'MANS' still have no directory prefixes.)
     Adding support for prefixes like that was one of the major ideas in
     'automake'; it has lasted pretty well.

     AutoMake is renamed to Automake (Tom seems to recall it was
     Franc,ois Pinard's doing).

     0.25 fixes a Perl 4 portability bug.

1995-12-18 Jim Meyering starts using Automake in GNU Textutils.
1995-12-31 Franc,ois Pinard starts using Automake in GNU tar.

1996-01-03 Automake 0.26
1996-01-03 Automake 0.27

     Of the many changes and suggestions sent by Franc,ois 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.

1996-01-13 Automake 0.28

     Automake starts scanning 'configure.in' for 'LIBOBJS' support.
     This is an important step because until this version Automake only
     knew about the 'Makefile.am's it processed.  'configure.in' was
     Autoconf's world and the link between Autoconf and Automake had to
     be done by the 'Makefile.am' author.  For instance, if 'config.h'
     was generated by 'configure', it was the package maintainer's
     responsibility to define the 'CONFIG_HEADER' variable in each
     'Makefile.am'.

     Succeeding releases will rely more and more on scanning
     'configure.in' to better automate the Autoconf integration.

     0.28 also introduces the 'AUTOMAKE_OPTIONS' variable and the
     '--gnu' and '--gnits' options, the latter being stricter.

1996-02-07 Automake 0.29

     Thanks to 'configure.in' scanning, 'CONFIG_HEADER' is gone, and
     rebuild rules for 'configure'-generated file are automatically
     output.

     'TEXINFOS' and 'MANS' converted to the uniform naming scheme.

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 (*note Releases::), and this
     proved to be really helpful later on.

     'EXTRA_PROGRAMS' finally replaces 'AM_PROGRAMS'.

     All the third-party Autoconf macros, written mostly by Franc,ois
     Pinard (and later Jim Meyering), are distributed in Automake's
     hand-written 'aclocal.m4' file.  Package maintainers are expected
     to extract the necessary macros from this file.  (In previous
     versions you had to copy and paste them from the manual...)

1996-03-11 Automake 0.31

     The test suite in 0.30 was run via a long 'check-local' rule.  Upon
     Ulrich Drepper's suggestion, 0.31 makes it an Automake rule output
     whenever the 'TESTS' variable is defined.

     'DIST_OTHER' is renamed to 'EXTRA_DIST', and the 'check_' prefix is
     introduced.  The syntax is now the same as today.

1996-03-15 Gordon Matzigkeit starts writing libtool.

1996-04-27 Automake 0.32

     '-hook' targets are introduced; an idea from Dieter Baron.

     '*.info' files, which were output in the build directory are now
     built in the source directory, because they are distributed.  It
     seems these files like to move back and forth as that will happen
     again in future versions.

1996-05-18 Automake 0.33

     Gord Matzigkeit's main two contributions:

        * very preliminary libtool support
        * the distcheck rule

     Although they were very basic at this point, these are probably
     among the top features for Automake today.

     Jim Meyering also provides the infamous 'jm_MAINTAINER_MODE', since
     then renamed to 'AM_MAINTAINER_MODE' and abandoned by its author
     (*note maintainer-mode: (automake)maintainer-mode.).

1996-05-28 Automake 1.0

     After only six months of heavy development, the 'automake' script
     is 3134 lines long, plus 973 lines of 'Makefile' fragments.  The
     package has 30 pages of documentation, and 38 test cases.
     '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.

1996-10-10 Kevin Dalley packages Automake 1.0 for Debian GNU/Linux.

1996-11-26 David J. 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 'ChangeLog' for 1997 lists only 7
     commits.

1997-02-28 <automake@gnu.ai.mit.edu> list alive

     The mailing list is announced as follows:
          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

     Before that people were discussing Automake privately, on the Gnits
     mailing list (which is not public either), and less frequently on
     'gnu.misc.discuss'.

     'gnu.ai.mit.edu' is now 'gnu.org', in case you never noticed.  The
     archives of the early years of the '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.

1997-06-22 Automake 1.2

     Automake developments continues, and more and more new Autoconf
     macros are required.  Distributing them in '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 'aclocal'
     ('aclocal' was actually started on 1996-07-28), a tool that
     automatically constructs an '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
     'AM_INIT_AUTOMAKE' macro that simplifies the creation of
     'configure.in'.

     Libtool is fully supported using '*_LTLIBRARIES'.

     The missing script is introduced by Franc,ois Pinard; it is meant
     to be a better solution than 'AM_MAINTAINER_MODE' (*note
     maintainer-mode: (automake)maintainer-mode.).

     Conditionals support was implemented by Ian Lance Taylor.  At the
     time, Tom and Ian were working on an internal project at Cygnus.
     They were using ILU, which is pretty similar to CORBA.  They wanted
     to integrate ILU into their build, which was all 'configure'-based,
     and Ian thought that adding conditionals to 'automake' was simpler
     than doing all the work in 'configure' (which was the standard at
     the time).  So this was actually funded by Cygnus.

     This very useful but tricky feature will take a lot of time to
     stabilize.  (At the time this text is written, there are still
     primaries that have not been updated to support conditional
     definitions in Automake 1.9.)

     The 'automake' script has almost doubled: 6089 lines of Perl, plus
     1294 lines of 'Makefile' fragments.

1997-07-08 Gordon Matzigkeit releases Libtool 1.0.

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.

1998-09-06 'sourceware.cygnus.com' is on-line.

     Sourceware was setup by Jason Molenda to host open source projects.

1998-09-19 Automake CVS repository moved to 'sourceware.cygnus.com'
1998-10-26 'sourceware.cygnus.com' announces it hosts Automake:
     Automake is now hosted on 'sourceware.cygnus.com'.  It has a
     publicly accessible CVS repository.  This CVS repository is a copy
     of the one Tom was using on his machine, which in turn is based on
     a copy of the CVS repository of David MacKenzie.  This is why we
     still have to full source history.  (Automake was on Sourceware
     until 2007-10-29, when it moved to a git repository on
     'savannah.gnu.org', but the Sourceware host had been renamed to
     'sources.redhat.com'.)

     The oldest file in the administrative directory of the CVS
     repository that was created on Sourceware is dated 1998-09-19,
     while the announcement that 'automake' and 'autoconf' had joined
     'sourceware' was made on 1998-10-26.  They were among the first
     projects to be hosted there.

     The heedful reader will have noticed Automake was exactly 4 years
     old on 1998-09-19.

1999-01-05 Ben Elliston releases Autoconf 2.13.

1999-01-14 Automake 1.4

     This release adds support for Fortran 77 and for the 'include'
     statement.  Also, '+=' assignments are introduced, but it is still
     quite easy to fool Automake when mixing this with conditionals.

     These two releases, Automake 1.4 and Autoconf 2.13 make a duo that
     will be used together for years.

     'automake' is 7228 lines, plus 1591 lines of Makefile fragment, 20
     macros (some 1.3 macros were finally contributed back to Autoconf),
     197 test cases, and 51 pages of documentation.

1999-03-27 The '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 '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.

     *Note Dependency Tracking Evolution::, for more details about the
     evolution of automatic dependency tracking in Automake.

1999-11-21 The '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.

2000-05-10

     Since September 1999 and until 2003, Akim Demaille will be
     zealously revamping Autoconf.

          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 <autoconf@gnu.org>

     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.

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 :)

2001-01-28

     Akim sends a batch of 14 patches to <automake@gnu.org>.

          Aiieeee!  I was dreading the day that the Demaillator turned
          his sights on automake... and now it has arrived!  - Tom
          Tromey

     It's only the beginning: in two months he will send 192 patches.
     Then he would slow down so Tom can catch up and review all this.
     Initially Tom actually read all of these patches, then he probably
     trustingly answered OK to most of them, and finally gave up and let
     Akim apply whatever he wanted.  There was no way to keep up with
     that patch rate.

          Anyway the patch below won't apply since it predates Akim's
          sourcequake; I have yet to figure where the relevant passage
          has been moved :) - Alexandre Duret-Lutz

     All of these patches were sent to and discussed on
     <automake@gnu.org>, so subscribed users were literally drowning in
     technical mails.  Eventually, the <automake-patches@gnu.org>
     mailing list was created in May.

     Year after year, Automake had drifted away from its initial design:
     construct 'Makefile.in' by assembling various 'Makefile' fragments.
     In 1.4, lots of 'Makefile' rules are being emitted at various
     places in the 'automake' script itself; this does not help ensuring
     a consistent treatment of these rules (for instance making sure
     that user-defined rules override Automake's own rules).  One of
     Akim's goal was moving all of these hard-coded rules to separate
     'Makefile' fragments, so the logic could be centralized in a
     'Makefile' fragment processor.

     Another significant contribution of Akim is the interface with the
     "trace" feature of Autoconf.  The way to scan 'configure.in' at
     this time was to read the file and grep the various macro of
     interest to Automake.  Doing so could break in many unexpected
     ways; 'automake' could miss some definition (for instance
     'AC_SUBST([$1], [$2])' where the arguments are known only when M4
     is run), or conversely it could detect some macro that was not
     expanded (because it is called conditionally).  In the CVS version
     of Autoconf, Akim had implemented the '--trace' option, which
     provides accurate information about where macros are actually
     called and with what arguments.  Akim will equip Automake with a
     second 'configure.in' scanner that uses this '--trace' interface.
     Since it was not sensible to drop the Autoconf 2.13 compatibility
     yet, this experimental scanner was only used when an environment
     variable was set, the traditional grep-scanner being still the
     default.

2001-04-25 Gary V. 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.

2001-05-08 Automake 1.4-p1
2001-05-24 Automake 1.4-p2

     Gary V. Vaughan, the principal Libtool maintainer, makes a "patch
     release" of Automake:

          The main purpose of this release is to have a stable automake
          which is compatible with the latest stable libtool.

     The release also contains obvious fixes for bugs in Automake 1.4,
     some of which were reported almost monthly.

2001-05-21 Akim Demaille releases Autoconf 2.50

2001-06-07 Automake 1.4-p3
2001-06-10 Automake 1.4-p4
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 'configure.ac' over 'configure.in', and it introduces a
     new syntax for 'AC_OUTPUT'ing files.

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:
        * The new dependency tracking scheme that uses 'depcomp'.  Aside
          from the improvement on the dependency tracking itself (*note
          Dependency Tracking Evolution::), this also streamlines the
          use of 'automake'-generated 'Makefile.in's as the
          'Makefile.in's used during development are now the same as
          those used in distributions.  Before that the 'Makefile.in's
          generated for maintainers required GNU 'make' and GCC, they
          were different from the portable 'Makefile' generated for
          distribution; this was causing some confusion.

        * Support for per-target compilation flags.

        * Support for reference to files in subdirectories in most
          'Makefile.am' variables.

        * Introduction of the 'dist_', 'nodist_', and 'nobase_'
          prefixes.
        * Perl 4 support is finally dropped.

     1.5 did break several packages that worked with 1.4.  Enough so
     that Linux distributions could not easily install the new Automake
     version without breaking many of the packages for which they had to
     run 'automake'.

     Some of these breakages were effectively bugs that would eventually
     be fixed in the next release.  However, a lot of damage was caused
     by some changes made deliberately to render Automake stricter on
     some setup we did consider bogus.  For instance, 'make distcheck'
     was improved to check that 'make uninstall' did remove all the
     files 'make install' installed, that 'make distclean' did not omit
     some file, and that a VPATH build would work even if the source
     directory was read-only.  Similarly, Automake now rejects multiple
     definitions of the same variable (because that would mix very badly
     with conditionals), and '+=' assignments with no previous
     definition.  Because these changes all occurred suddenly after 1.4
     had been established for more than two years, it hurt users.

     To make matter worse, meanwhile Autoconf (now at version 2.52) was
     facing similar troubles, for similar reasons.

2002-03-05 Automake 1.6

     This release introduced versioned installation (*note API
     Versioning: (automake)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 'automake-1.6', call all its
     bug-fix versions identically, and switch to 'automake-1.7' for the
     next release that adds new features or changes some rules.  This
     scheme implies maintaining a bug-fix branch in addition to the
     development trunk, which means more work from the maintainer, but
     providing regular bug-fix releases proved to be really worthwhile.

     Like 1.5, 1.6 also introduced a bunch of incompatibilities,
     intentional or not.  Perhaps the more annoying was the dependence
     on the newly released Autoconf 2.53.  Autoconf seemed to have
     stabilized enough since its explosive 2.50 release and included
     changes required to fix some bugs in Automake.  In order to upgrade
     to Automake 1.6, people now had to upgrade Autoconf too; for some
     packages it was no picnic.

     While versioned installation helped people to upgrade, it also
     unfortunately allowed people not to upgrade.  At the time of
     writing, some Linux distributions are shipping packages for
     Automake 1.4, 1.5, 1.6, 1.7, 1.8, and 1.9.  Most of these still
     install 1.4 by default.  Some distribution also call 1.4 the
     "stable" version, and present "1.9" as the development version;
     this does not really makes sense since 1.9 is way more solid than
     1.4.  All this does not help the newcomer.

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 '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.

2002-06-14 Automake 1.6.2

2002-07-28 Automake 1.6.3
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.

2002-09-25 Automake 1.7

     This release switches to the new 'configure.ac' scanner Akim was
     experimenting in 1.5.

2002-10-16 Automake 1.7.1
2002-12-06 Automake 1.7.2
2003-02-20 Automake 1.7.3
2003-04-23 Automake 1.7.4
2003-05-18 Automake 1.7.5
2003-07-10 Automake 1.7.6
2003-09-07 Automake 1.7.7
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.

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 'Makefile.in' generated by automake...

2003-11-09 Automake 1.7.9

2003-12-10 Automake 1.8

     The most striking update is probably that of 'aclocal'.

     'aclocal' now uses 'm4_include' in the produced 'aclocal.m4' when
     the included macros are already distributed with the package (an
     idiom used in many packages), which reduces code duplication.  Many
     people liked that, but in fact this change was really introduced to
     fix a bug in rebuild rules: 'Makefile.in' must be rebuilt whenever
     a dependency of 'configure' changes, but all the 'm4' files
     included in 'aclocal.m4' where unknown from 'automake'.  Now
     'automake' can just trace the 'm4_include's to discover the
     dependencies.

     'aclocal' also starts using the '--trace' Autoconf option in order
     to discover used macros more accurately.  This will turn out to be
     very tricky (later releases will improve this) as people had
     devised many ways to cope with the limitation of previous 'aclocal'
     versions, notably using handwritten 'm4_include's: '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.

2004-01-11 Automake 1.8.1
2004-01-12 Automake 1.8.2
2004-03-07 Automake 1.8.3
2004-04-25 Automake 1.8.4
2004-05-16 Automake 1.8.5

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 '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.

2004-08-11 Automake 1.9.1
2004-09-19 Automake 1.9.2

     Automake has ten years.  This chapter of the manual was initially
     written for this occasion.

2007-10-29 Automake repository moves to 'savannah.gnu.org'
     and uses git as primary repository.


File: automake-history.info,  Node: Dependency Tracking Evolution,  Next: Releases,  Prev: Timeline,  Up: Top

2 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


File: automake-history.info,  Node: First Take on Dependencies,  Next: Dependencies As Side Effects,  Up: Dependency Tracking Evolution

2.1 First Take on Dependency Tracking
=====================================

Description
-----------

Our first attempt at automatic dependency tracking was based on the
method recommended by GNU 'make'.  (*note Generating Prerequisites
Automatically: (make)Automatic Prerequisites.)

   This version worked by precomputing dependencies ahead of time.  For
each source file, it had a special '.P' file that held the dependencies.
There was a rule to generate a '.P' file by invoking the compiler
appropriately.  All such '.P' files were included by the 'Makefile',
thus implicitly becoming dependencies of 'Makefile'.

Bugs
----

This approach had several critical bugs.

   * The code to generate the '.P' file relied on 'gcc'.  (A limitation,
     not technically a bug.)
   * The dependency tracking mechanism itself relied on GNU 'make'.  (A
     limitation, not technically a bug.)
   * Because each '.P' file was a dependency of 'Makefile', this meant
     that dependency tracking was done eagerly by 'make'.  For instance,
     '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.
   * As dependency tracking was done as a pre-pass, compile times were
     doubled-the compiler had to be run twice per source file.
   * 'make dist' re-ran 'automake' to generate a 'Makefile' that did not
     have automatic dependency tracking (and that was thus portable to
     any version of '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 '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 '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.

Historical Note
---------------

The code generated by Automake is often inspired by the '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.)


File: automake-history.info,  Node: Dependencies As Side Effects,  Next: Dependencies for the User,  Prev: First Take on Dependencies,  Up: Dependency Tracking Evolution

2.2 Dependencies As Side Effects
================================

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 '.P' files were included using the '-include'
command, which let us create these files lazily.  This avoided the '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).

Bugs
----

   * This approach also relied on the existence of 'gcc' and GNU 'make'.
     (A limitation, not technically a bug.)
   * Dependency tracking was still done by the developer, so the
     problems from the first implementation relating to massaging of
     dependencies by 'make dist' were still in effect.
   * This implementation suffered from the "deleted header file"
     problem.  Suppose a lazily-created '.P' file includes a dependency
     on a given header file, like this:

          maude.o: maude.c something.h

     Now suppose that you remove 'something.h' and update 'maude.c' so
     that this include is no longer needed.  If you run 'make', you will
     get an error because there is no way to create 'something.h'.

     We fixed this problem in a later release by further massaging the
     output of 'gcc' to include a dummy dependency for each header file.


File: automake-history.info,  Node: Dependencies for the User,  Next: Techniques for Dependencies,  Prev: Dependencies As Side Effects,  Up: Dependency Tracking Evolution

2.3 Dependencies for the User
=============================

Description
-----------

The bugs associated with '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" 'Makefile.in's, leading to user complaints.
Also, the requirement for 'gcc' and GNU '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 ('depcomp') knows
about twelve different compilers (including a "compiler" that simply
invokes 'makedepend' and then the real compiler, which is assumed to be
a standard Unix-like C compiler with no way to do dependency tracking).

Bugs
----

   * Running a wrapper script for each compilation slows down the build.
   * Many users don't really care about precise dependencies.
   * 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.

   * 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 'BUILT_SOURCES' to list built headers
     (*note Sources: (automake)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.

   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 '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 'gcc' is detected at
'configure' time, we inline the dependency-generation code and do not
use the '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
'Makefile' (with or without 'depcomp'), the produced 'Makefile's are
larger.


File: automake-history.info,  Node: Techniques for Dependencies,  Prev: Dependencies for the User,  Up: Dependency Tracking Evolution

2.4 Techniques for Computing Dependencies
=========================================

There are actually several ways for a build tool like Automake to cause
tools to generate dependencies.

'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 'makedepend' are not
     completely precise; ordinarily they were conservative and
     discovered too many dependencies.
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.
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.  '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.
'LD_PRELOAD'
     Rather than use the file system, one could write a special library
     to intercept 'open' and other syscalls.  This technique is also
     quite powerful, but unfortunately it is not portable enough for use
     in 'automake'.

* Menu:

* Recommendations for Tool Writers::
* Future Directions for Dependencies::


File: automake-history.info,  Node: Recommendations for Tool Writers,  Next: Future Directions for Dependencies,  Up: Techniques for Dependencies

2.4.1 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 '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.


File: automake-history.info,  Node: Future Directions for Dependencies,  Prev: Recommendations for Tool Writers,  Up: Techniques for Dependencies

2.4.2 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.


File: automake-history.info,  Node: Releases,  Next: Copying This Manual,  Prev: Dependency Tracking Evolution,  Up: Top

3 Release Statistics
********************

The following table (inspired by 'perlhist(1)') quantifies the evolution
of Automake using these metrics:

Date, Rel
     The date and version of the release.
am
     The number of lines of the 'automake' script.
acl
     The number of lines of the 'aclocal' script.
pm
     The number of lines of the 'Perl' supporting modules.
'*.am'
     The number of lines of the 'Makefile' fragments.  The number in
     parentheses is the number of files.
m4
     The number of lines (and files) of Autoconf macros.
doc
     The number of pages of the documentation (the Postscript version).
t
     The number of test cases in the test suite.  Of those, the number
     in parentheses is the number of generated test cases.

Date         Rel      am     acl    pm     '*.am'      m4          doc   t
------------------------------------------------------------------------------------
1994-09-19   CVS      141                  299 (24)
1994-11-05   CVS      208                  332 (28)
1995-11-23   0.20     533                  458 (35)                9
1995-11-26   0.21     613                  480 (36)                11
1995-11-28   0.22     1116                 539 (38)                12
1995-11-29   0.23     1240                 541 (38)                12
1995-12-08   0.24     1462                 504 (33)                14
1995-12-10   0.25     1513                 511 (37)                15
1996-01-03   0.26     1706                 438 (36)                16
1996-01-03   0.27     1706                 438 (36)                16
1996-01-13   0.28     1964                 934 (33)                16
1996-02-07   0.29     2299                 936 (33)                17
1996-02-24   0.30     2544                 919 (32)    85 (1)      20    9
1996-03-11   0.31     2877                 919 (32)    85 (1)      29    17
1996-04-27   0.32     3058                 921 (31)    85 (1)      30    26
1996-05-18   0.33     3110                 926 (31)    105 (1)     30    35
1996-05-28   1.0      3134                 973 (32)    105 (1)     30    38
1997-06-22   1.2      6089   385           1294 (36)   592 (20)    37    126
1998-04-05   1.3      6415   422           1470 (39)   741 (23)    39    156
1999-01-14   1.4      7240   426           1591 (40)   734 (20)    51    197
2001-05-08   1.4-p1   7251   426           1591 (40)   734 (20)    51    197
2001-05-24   1.4-p2   7268   439           1591 (40)   734 (20)    49    197
2001-06-07   1.4-p3   7312   439           1591 (40)   734 (20)    49    197
2001-06-10   1.4-p4   7321   439           1591 (40)   734 (20)    49    198
2001-07-15   1.4-p5   7228   426           1596 (40)   734 (20)    51    198
2001-08-23   1.5      8016   475    600    2654 (39)   1166 (29)   63    327
2002-03-05   1.6      8465   475    1136   2732 (39)   1603 (27)   66    365
2002-04-11   1.6.1    8544   475    1136   2741 (39)   1603 (27)   66    372
2002-06-14   1.6.2    8575   475    1136   2800 (39)   1609 (27)   67    386
2002-07-28   1.6.3    8600   475    1153   2809 (39)   1609 (27)   67    391
2002-07-28   1.4-p6   7332   455           1596 (40)   735 (20)    49    197
2002-09-25   1.7      9189   471    1790   2965 (39)   1606 (28)   73    430
2002-10-16   1.7.1    9229   475    1790   2977 (39)   1606 (28)   73    437
2002-12-06   1.7.2    9334   475    1790   2988 (39)   1606 (28)   77    445
2003-02-20   1.7.3    9389   475    1790   3023 (39)   1651 (29)   84    448
2003-04-23   1.7.4    9429   475    1790   3031 (39)   1644 (29)   85    458
2003-05-18   1.7.5    9429   475    1790   3033 (39)   1645 (29)   85    459
2003-07-10   1.7.6    9442   475    1790   3033 (39)   1660 (29)   85    461
2003-09-07   1.7.7    9443   475    1790   3041 (39)   1660 (29)   90    467
2003-10-07   1.7.8    9444   475    1790   3041 (39)   1660 (29)   90    468
2003-11-09   1.7.9    9444   475    1790   3048 (39)   1660 (29)   90    468
2003-12-10   1.8      7171   585    7730   3236 (39)   1666 (31)   104   521
2004-01-11   1.8.1    7217   663    7726   3287 (39)   1686 (31)   104   525
2004-01-12   1.8.2    7217   663    7726   3288 (39)   1686 (31)   104   526
2004-03-07   1.8.3    7214   686    7735   3303 (39)   1695 (31)   111   530
2004-04-25   1.8.4    7214   686    7736   3310 (39)   1701 (31)   112   531
2004-05-16   1.8.5    7240   686    7736   3299 (39)   1701 (31)   112   533
2004-07-28   1.9      7508   715    7794   3352 (40)   1812 (32)   115   551
2004-08-11   1.9.1    7512   715    7794   3354 (40)   1812 (32)   115   552
2004-09-19   1.9.2    7512   715    7794   3354 (40)   1812 (32)   132   554
2004-11-01   1.9.3    7507   718    7804   3354 (40)   1812 (32)   134   556
2004-12-18   1.9.4    7508   718    7856   3361 (40)   1811 (32)   140   560
2005-02-13   1.9.5    7523   719    7859   3373 (40)   1453 (32)   142   562
2005-07-10   1.9.6    7539   699    7867   3400 (40)   1453 (32)   144   570
2006-10-15   1.10     7859   1072   8024   3512 (40)   1496 (34)   172   604
2008-01-19   1.10.1   7870   1089   8025   3520 (40)   1499 (34)   173   617
2008-11-23   1.10.2   7882   1089   8027   3540 (40)   1509 (34)   176   628
2009-05-17   1.11     8721   1092   8289   4164 (42)   1714 (37)   181   732 (20)


File: automake-history.info,  Node: Copying This Manual,  Prev: Releases,  Up: Top

Appendix A Copying This Manual
******************************

* Menu:

* GNU Free Documentation License::  License for copying this manual


File: automake-history.info,  Node: GNU Free Documentation License,  Up: Copying This Manual

A.1 GNU Free Documentation License
==================================

                     Version 1.3, 3 November 2008

     Copyright (C) 2000-2013 Free Software Foundation, Inc.
     <http://fsf.org/>

     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

  0. PREAMBLE

     The purpose of this License is to make a manual, textbook, or other
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.

     This License is a kind of "copyleft", which means that derivative
     works of the document must themselves be free in the same sense.
     It complements the GNU General Public License, which is a copyleft
     license designed for free software.

     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does.  But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book.  We
     recommend this License principally for works whose purpose is
     instruction or reference.

  1. APPLICABILITY AND DEFINITIONS

     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it can
     be distributed under the terms of this License.  Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein.  The
     "Document", below, refers to any such manual or work.  Any member
     of the public is a licensee, and is addressed as "you".  You accept
     the license if you copy, modify or distribute the work in a way
     requiring permission under copyright law.

     A "Modified Version" of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.

     A "Secondary Section" is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.

     The "Invariant Sections" are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in the
     notice that says that the Document is released under this License.
     If a section does not fit the above definition of Secondary then it
     is not allowed to be designated as Invariant.  The Document may
     contain zero Invariant Sections.  If the Document does not identify
     any Invariant Sections then there are none.

     The "Cover Texts" are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License.  A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.

     A "Transparent" copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images composed
     of pixels) generic paint programs or (for drawings) some widely
     available drawing editor, and that is suitable for input to text
     formatters or for automatic translation to a variety of formats
     suitable for input to text formatters.  A copy made in an otherwise
     Transparent file format whose markup, or absence of markup, has
     been arranged to thwart or discourage subsequent modification by
     readers is not Transparent.  An image format is not Transparent if
     used for any substantial amount of text.  A copy that is not
     "Transparent" is called "Opaque".

     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and standard-conforming
     simple HTML, PostScript or PDF designed for human modification.
     Examples of transparent image formats include PNG, XCF and JPG.
     Opaque formats include proprietary formats that can be read and
     edited only by proprietary word processors, SGML or XML for which
     the DTD and/or processing tools are not generally available, and
     the machine-generated HTML, PostScript or PDF produced by some word
     processors for output purposes only.

     The "Title Page" means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page.  For
     works in formats which do not have any title page as such, "Title
     Page" means the text near the most prominent appearance of the
     work's title, preceding the beginning of the body of the text.

     The "publisher" means any person or entity that distributes copies
     of the Document to the public.

     A section "Entitled XYZ" means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
     To "Preserve the Title" of such a section when you modify the
     Document means that it remains a section "Entitled XYZ" according
     to this definition.

     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document.  These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.

  2. VERBATIM COPYING

     You may copy and distribute the Document in any medium, either
     commercially or noncommercially, provided that this License, the
     copyright notices, and the license notice saying this License
     applies to the Document are reproduced in all copies, and that you
     add no other conditions whatsoever to those of this License.  You
     may not use technical measures to obstruct or control the reading
     or further copying of the copies you make or distribute.  However,
     you may accept compensation in exchange for copies.  If you
     distribute a large enough number of copies you must also follow the
     conditions in section 3.

     You may also lend copies, under the same conditions stated above,
     and you may publicly display copies.

  3. COPYING IN QUANTITY

     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document's license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     of these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover.  Both covers must also clearly
     and legibly identify you as the publisher of these copies.  The
     front cover must present the full title with all words of the title
     equally prominent and visible.  You may add other material on the
     covers in addition.  Copying with changes limited to the covers, as
     long as they preserve the title of the Document and satisfy these
     conditions, can be treated as verbatim copying in other respects.

     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.

     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a machine-readable
     Transparent copy along with each Opaque copy, or state in or with
     each Opaque copy a computer-network location from which the general
     network-using public has access to download using public-standard
     network protocols a complete Transparent copy of the Document, free
     of added material.  If you use the latter option, you must take
     reasonably prudent steps, when you begin distribution of Opaque
     copies in quantity, to ensure that this Transparent copy will
     remain thus accessible at the stated location until at least one
     year after the last time you distribute an Opaque copy (directly or
     through your agents or retailers) of that edition to the public.

     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of copies,
     to give them a chance to provide you with an updated version of the
     Document.

  4. MODIFICATIONS

     You may copy and distribute a Modified Version of the Document
     under the conditions of sections 2 and 3 above, provided that you
     release the Modified Version under precisely this License, with the
     Modified Version filling the role of the Document, thus licensing
     distribution and modification of the Modified Version to whoever
     possesses a copy of it.  In addition, you must do these things in
     the Modified Version:

       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of previous
          versions (which should, if there were any, be listed in the
          History section of the Document).  You may use the same title
          as a previous version if the original publisher of that
          version gives permission.

       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.

       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.

       D. Preserve all the copyright notices of the Document.

       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.

       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.

       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document's
          license notice.

       H. Include an unaltered copy of this License.

       I. Preserve the section Entitled "History", Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on the
          Title Page.  If there is no section Entitled "History" in the
          Document, create one stating the title, year, authors, and
          publisher of the Document as given on its Title Page, then add
          an item describing the Modified Version as stated in the
          previous sentence.

       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on.  These may be placed in the
          "History" section.  You may omit a network location for a work
          that was published at least four years before the Document
          itself, or if the original publisher of the version it refers
          to gives permission.

       K. For any section Entitled "Acknowledgements" or "Dedications",
          Preserve the Title of the section, and preserve in the section
          all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.

       L. Preserve all the Invariant Sections of the Document, unaltered
          in their text and in their titles.  Section numbers or the
          equivalent are not considered part of the section titles.

       M. Delete any section Entitled "Endorsements".  Such a section
          may not be included in the Modified Version.

       N. Do not retitle any existing section to be Entitled
          "Endorsements" or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     If the Modified Version includes new front-matter sections or
     appendices that qualify as Secondary Sections and contain no
     material copied from the Document, you may at your option designate
     some or all of these sections as invariant.  To do this, add their
     titles to the list of Invariant Sections in the Modified Version's
     license notice.  These titles must be distinct from any other
     section titles.

     You may add a section Entitled "Endorsements", provided it contains
     nothing but endorsements of your Modified Version by various
     parties--for example, statements of peer review or that the text
     has been approved by an organization as the authoritative
     definition of a standard.

     You may add a passage of up to five words as a Front-Cover Text,
     and a passage of up to 25 words as a Back-Cover Text, to the end of
     the list of Cover Texts in the Modified Version.  Only one passage
     of Front-Cover Text and one of Back-Cover Text may be added by (or
     through arrangements made by) any one entity.  If the Document
     already includes a cover text for the same cover, previously added
     by you or by arrangement made by the same entity you are acting on
     behalf of, you may not add another; but you may replace the old
     one, on explicit permission from the previous publisher that added
     the old one.

     The author(s) and publisher(s) of the Document do not by this
     License give permission to use their names for publicity for or to
     assert or imply endorsement of any Modified Version.

  5. COMBINING DOCUMENTS

     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination all
     of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.

     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy.  If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.

     In the combination, you must combine any sections Entitled
     "History" in the various original documents, forming one section
     Entitled "History"; likewise combine any sections Entitled
     "Acknowledgements", and any sections Entitled "Dedications".  You
     must delete all sections Entitled "Endorsements."

  6. COLLECTIONS OF DOCUMENTS

     You may make a collection consisting of the Document and other
     documents released under this License, and replace the individual
     copies of this License in the various documents with a single copy
     that is included in the collection, provided that you follow the
     rules of this License for verbatim copying of each of the documents
     in all other respects.

     You may extract a single document from such a collection, and
     distribute it individually under this License, provided you insert
     a copy of this License into the extracted document, and follow this
     License in all other respects regarding verbatim copying of that
     document.

  7. AGGREGATION WITH INDEPENDENT WORKS

     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of a
     storage or distribution medium, is called an "aggregate" if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation's users beyond what the individual
     works permit.  When the Document is included in an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.

     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document's Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.

  8. TRANSLATION

     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections.  You may include a
     translation of this License, and all the license notices in the
     Document, and any Warranty Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers.  In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.

     If a section in the Document is Entitled "Acknowledgements",
     "Dedications", or "History", the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.

  9. TERMINATION

     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided under this License.  Any attempt
     otherwise to copy, modify, sublicense, or distribute it is void,
     and will automatically terminate your rights under this License.

     However, if you cease all violation of this License, then your
     license from a particular copyright holder is reinstated (a)
     provisionally, unless and until the copyright holder explicitly and
     finally terminates your license, and (b) permanently, if the
     copyright holder fails to notify you of the violation by some
     reasonable means prior to 60 days after the cessation.

     Moreover, your license from a particular copyright holder is
     reinstated permanently if the copyright holder notifies you of the
     violation by some reasonable means, this is the first time you have
     received notice of violation of this License (for any work) from
     that copyright holder, and you cure the violation prior to 30 days
     after your receipt of the notice.

     Termination of your rights under this section does not terminate
     the licenses of parties who have received copies or rights from you
     under this License.  If your rights have been terminated and not
     permanently reinstated, receipt of a copy of some or all of the
     same material does not give you any rights to use it.

  10. FUTURE REVISIONS OF THIS LICENSE

     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time.  Such new
     versions will be similar in spirit to the present version, but may
     differ in detail to address new problems or concerns.  See
     <http://www.gnu.org/copyleft/>.

     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License "or any later version" applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation.  If the
     Document does not specify a version number of this License, you may
     choose any version ever published (not as a draft) by the Free
     Software Foundation.  If the Document specifies that a proxy can
     decide which future versions of this License can be used, that
     proxy's public statement of acceptance of a version permanently
     authorizes you to choose that version for the Document.

  11. RELICENSING

     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
     World Wide Web server that publishes copyrightable works and also
     provides prominent facilities for anybody to edit those works.  A
     public wiki that anybody can edit is an example of such a server.
     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
     site means any set of copyrightable works thus published on the MMC
     site.

     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
     license published by Creative Commons Corporation, a not-for-profit
     corporation with a principal place of business in San Francisco,
     California, as well as future copyleft versions of that license
     published by that same organization.

     "Incorporate" means to publish or republish a Document, in whole or
     in part, as part of another Document.

     An MMC is "eligible for relicensing" if it is licensed under this
     License, and if all works that were first published under this
     License somewhere other than this MMC, and subsequently
     incorporated in whole or in part into the MMC, (1) had no cover
     texts or invariant sections, and (2) were thus incorporated prior
     to November 1, 2008.

     The operator of an MMC Site may republish an MMC contained in the
     site under CC-BY-SA on the same site at any time before August 1,
     2009, provided the MMC is eligible for relicensing.

ADDENDUM: How to use this License for your documents
====================================================

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

       Copyright (C)  YEAR  YOUR NAME.
       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, no Front-Cover Texts, and no Back-Cover
       Texts.  A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

   If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts."  line with this:

         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.

   If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

   If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of free
software license, such as the GNU General Public License, to permit
their use in free software.



Tag Table:
Node: Top702
Node: Timeline2236
Node: Dependency Tracking Evolution33697
Node: First Take on Dependencies34539
Node: Dependencies As Side Effects37197
Node: Dependencies for the User39256
Node: Techniques for Dependencies44286
Node: Recommendations for Tool Writers45984
Node: Future Directions for Dependencies46703
Node: Releases47173
Node: Copying This Manual52560
Node: GNU Free Documentation License52787

End Tag Table