This is automake.info, produced by makeinfo version 4.13 from
automake.texi.

This manual is for GNU Automake (version 1.11.2, 21 December 2011), a
program that creates GNU standards-compliant Makefiles from template
files.

   Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 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."


INFO-DIR-SECTION Software development
START-INFO-DIR-ENTRY
* Automake: (automake).         Making GNU standards-compliant Makefiles.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Individual utilities
START-INFO-DIR-ENTRY
* aclocal: (automake)Invoking aclocal.          Generating aclocal.m4.
* automake: (automake)Invoking Automake.        Generating Makefile.in.
END-INFO-DIR-ENTRY


File: automake.info,  Node: Checking the Distribution,  Next: The Types of Distributions,  Prev: The dist Hook,  Up: Dist

14.4 Checking the Distribution
==============================

Automake also generates a `distcheck' rule that can be of help to
ensure that a given distribution will actually work.  `distcheck' makes
a distribution, then tries to do a `VPATH' build (*note VPATH
Builds::), run the test suite, and finally make another tarball to
ensure the distribution is self-contained.

   Building the package involves running `./configure'.  If you need to
supply additional flags to `configure', define them in the
`AM_DISTCHECK_CONFIGURE_FLAGS' variable in your top-level
`Makefile.am'.  The user can still extend or override the flags
provided there by defining the `DISTCHECK_CONFIGURE_FLAGS' variable, on
the command line when invoking `make'.

   Still, developers are encouraged to strive to make their code
buildable without requiring any special configure option; thus, in
general, you shouldn't define `AM_DISTCHECK_CONFIGURE_FLAGS'. However,
there might be few scenarios in which the use of this variable is
justified.  GNU `m4' offers an example.  GNU `m4' configures by default
with its experimental and seldom used "changeword" feature disabled; so
in its case it is useful to have `make distcheck' run configure with
the `--with-changeword' option, to ensure that the code for changeword
support still compiles correctly.  GNU `m4' also employs the
`AM_DISTCHECK_CONFIGURE_FLAGS' variable to stress-test the use of
`--program-prefix=g', since at one point the `m4' build system had a
bug where `make installcheck' was wrongly assuming it could blindly
test "`m4'", rather than the just-installed "`gm4'".

   If the `distcheck-hook' rule is defined in your top-level
`Makefile.am', then it will be invoked by `distcheck' after the new
distribution has been unpacked, but before the unpacked copy is
configured and built.  Your `distcheck-hook' can do almost anything,
though as always caution is advised.  Generally this hook is used to
check for potential distribution errors not caught by the standard
mechanism.  Note that `distcheck-hook' as well as
`AM_DISTCHECK_CONFIGURE_FLAGS' and `DISTCHECK_CONFIGURE_FLAGS' are not
honored in a subpackage `Makefile.am', but the flags from
`AM_DISTCHECK_CONFIGURE_FLAGS' and `DISTCHECK_CONFIGURE_FLAGS' are
passed down to the `configure' script of the subpackage.

   Speaking of potential distribution errors, `distcheck' also ensures
that the `distclean' rule actually removes all built files.  This is
done by running `make distcleancheck' at the end of the `VPATH' build.
By default, `distcleancheck' will run `distclean' and then make sure
the build tree has been emptied by running
`$(distcleancheck_listfiles)'.  Usually this check will find generated
files that you forgot to add to the `DISTCLEANFILES' variable (*note
Clean::).

   The `distcleancheck' behavior should be OK for most packages,
otherwise you have the possibility to override the definition of either
the `distcleancheck' rule, or the `$(distcleancheck_listfiles)'
variable.  For instance, to disable `distcleancheck' completely, add
the following rule to your top-level `Makefile.am':

     distcleancheck:
             @:

   If you want `distcleancheck' to ignore built files that have not
been cleaned because they are also part of the distribution, add the
following definition instead:

     distcleancheck_listfiles = \
       find . -type f -exec sh -c 'test -f $(srcdir)/$$1 || echo $$1' \
            sh '{}' ';'

   The above definition is not the default because it's usually an
error if your Makefiles cause some distributed files to be rebuilt when
the user build the package.  (Think about the user missing the tool
required to build the file; or if the required tool is built by your
package, consider the cross-compilation case where it can't be run.)
There is an entry in the FAQ about this (*note distcleancheck::), make
sure you read it before playing with `distcleancheck_listfiles'.

   `distcheck' also checks that the `uninstall' rule works properly,
both for ordinary and `DESTDIR' builds.  It does this by invoking `make
uninstall', and then it checks the install tree to see if any files are
left over.  This check will make sure that you correctly coded your
`uninstall'-related rules.

   By default, the checking is done by the `distuninstallcheck' rule,
and the list of files in the install tree is generated by
`$(distuninstallcheck_listfiles)' (this is a variable whose value is a
shell command to run that prints the list of files to stdout).

   Either of these can be overridden to modify the behavior of
`distcheck'.  For instance, to disable this check completely, you would
write:

     distuninstallcheck:
             @:


File: automake.info,  Node: The Types of Distributions,  Prev: Checking the Distribution,  Up: Dist

14.5 The Types of Distributions
===============================

Automake generates rules to provide archives of the project for
distributions in various formats.  Their targets are:

`dist-bzip2'
     Generate a bzip2 tar archive of the distribution.  bzip2 archives
     are frequently smaller than gzipped archives.  By default, this
     rule makes `bzip2' use a compression option of `-9'.  To make it
     use a different one, set the `BZIP2' environment variable.  For
     example, `make dist-bzip2 BZIP2=-7'.  

`dist-gzip'
     Generate a gzip tar archive of the distribution.  

`dist-lzma'
     Generate an `lzma' tar archive of the distribution.  `lzma'
     archives are frequently smaller than `bzip2'-compressed archives.
     The `lzma' format is obsolete, you should use the `xz' format
     instead.  

`dist-shar'
     Generate a shar archive of the distribution.  

`dist-xz'
     Generate an `xz' tar archive of the distribution.  `xz' archives
     are frequently smaller than `bzip2'-compressed archives.  The `xz'
     format displaces the obsolete `lzma' format.  By default, this
     rule makes `xz' use a compression option of `-e'.  To make it use
     a different one, set the `XZ_OPT' environment variable.  For
     example, run this command to use the default compression ratio,
     but with a progress indicator: `make dist-xz XZ_OPT=-7e'.  

`dist-zip'
     Generate a zip archive of the distribution.  

`dist-tarZ'
     Generate a compressed tar archive of the distribution.  

   The rule `dist' (and its historical synonym `dist-all') will create
archives in all the enabled formats, *note Options::.  By default, only
the `dist-gzip' target is hooked to `dist'.


File: automake.info,  Node: Tests,  Next: Rebuilding,  Prev: Dist,  Up: Top

15 Support for test suites
**************************

Automake supports three forms of test suites, the first two of which
are very similar.

* Menu:

* Simple Tests::                Listing programs and scripts in `TESTS'
* Simple Tests using parallel-tests::  More powerful test driver
* DejaGnu Tests::               Interfacing with the external testing framework
* Install Tests::               Running tests on installed packages


File: automake.info,  Node: Simple Tests,  Next: Simple Tests using parallel-tests,  Up: Tests

15.1 Simple Tests
=================

If the variable `TESTS' is defined, its value is taken to be a list of
programs or scripts to run in order to do the testing.  Programs
needing data files should look for them in `srcdir' (which is both an
environment variable and a make variable) so they work when building in
a separate directory (*note Build Directories: (autoconf)Build
Directories.), and in particular for the `distcheck' rule (*note
Checking the Distribution::).

   For each of the `TESTS', the result of execution is printed along
with the test name, where `PASS' denotes a successful test, `FAIL'
denotes a failed test, `XFAIL' an expected failure, `XPASS' an
unexpected pass for a test that is supposed to fail, and `SKIP' denotes
a skipped test.

   The number of failures will be printed at the end of the run.  If a
given test program exits with a status of 77, then its result is ignored
in the final count.  This feature allows non-portable tests to be
ignored in environments where they don't make sense.

   If the Automake option `color-tests' is used (*note Options::) and
standard output is connected to a capable terminal, then the test
results and the summary are colored appropriately.  The user can disable
colored output by setting the `make' variable `AM_COLOR_TESTS=no', or
force colored output even without a connecting terminal with
`AM_COLOR_TESTS=always'.

   Note that the semantics of some `make' implementations when used in
parallel mode (*note Parallel make: (autoconf)Parallel make.)  can
cause the automatic detection of a connection to a capable terminal to
fail.  In that case, you can still resort to the use of
`AM_COLOR_TESTS=always'.

   The variable `TESTS_ENVIRONMENT' can be used to set environment
variables for the test run; the environment variable `srcdir' is set in
the rule.  If all your test programs are scripts, you can also set
`TESTS_ENVIRONMENT' to an invocation of the shell (e.g.  `$(SHELL) -x'
can be useful for debugging the tests), or any other interpreter.  For
instance, the following setup may be used to run tests with Perl:

     TESTS_ENVIRONMENT = $(PERL) -Mstrict -w
     TESTS = foo.pl bar.pl baz.pl

   Note that the `parallel-tests' driver provides a more elegant way to
achieve the same effect, freeing the `TESTS_ENVIRONMENT' variable for
the user to override (*note Simple Tests using parallel-tests::).

   You may define the variable `XFAIL_TESTS' to a list of tests
(usually a subset of `TESTS') that are expected to fail.  This will
reverse the result of those tests.

   Automake ensures that each file listed in `TESTS' is built before
any tests are run; you can list both source and derived programs (or
scripts) in `TESTS'; the generated rule will look both in `srcdir' and
`.'.  For instance, you might want to run a C program as a test.  To do
this you would list its name in `TESTS' and also in `check_PROGRAMS',
and then specify it as you would any other program.

   Programs listed in `check_PROGRAMS' (and `check_LIBRARIES',
`check_LTLIBRARIES'...) are only built during `make check', not during
`make all'.  You should list there any program needed by your tests
that does not need to be built by `make all'.  Note that
`check_PROGRAMS' are _not_ automatically added to `TESTS' because
`check_PROGRAMS' usually lists programs used by the tests, not the
tests themselves.  Of course you can set `TESTS = $(check_PROGRAMS)' if
all your programs are test cases.


File: automake.info,  Node: Simple Tests using parallel-tests,  Next: DejaGnu Tests,  Prev: Simple Tests,  Up: Tests

15.2 Simple Tests using `parallel-tests'
========================================

The option `parallel-tests' (*note Options::) enables a test suite
driver that is mostly compatible to the simple test driver described in
the previous section, but provides a few more features and slightly
different semantics.  It features concurrent execution of tests with
`make -j', allows to specify inter-test dependencies, lazy reruns of
tests that have not completed in a prior run, summary and verbose
output in `RST' (reStructuredText) and `HTML' format, and hard errors
for exceptional failures.  Similar to the simple test driver,
`TESTS_ENVIRONMENT', `AM_COLOR_TESTS', `XFAIL_TESTS', and the `check_*'
variables are honored, and the environment variable `srcdir' is set
during test execution.

   This test driver is still experimental and may undergo changes in
order to satisfy additional portability requirements.

   The driver operates by defining a set of `make' rules to create a
summary log file, `TEST_SUITE_LOG', which defaults to `test-suite.log'
and requires a `.log' suffix.  This file depends upon log files created
for each single test program listed in `TESTS', which in turn contain
all output produced by the corresponding tests.

   Each log file is created when the corresponding test has completed.
The set of log files is listed in the read-only variable `TEST_LOGS',
and defaults to `TESTS', with the executable extension if any (*note
EXEEXT::), as well as any suffix listed in `TEST_EXTENSIONS' removed,
and `.log' appended.  Results are undefined if a test file name ends in
several concatenated suffixes.  `TEST_EXTENSIONS' defaults to `.test';
it can be overridden by the user, in which case any extension listed in
it must be constituted by a dot, followed by a non-digit alphabetic
character, followed by any number of alphabetic characters.  For
example, `.sh', `.T' and `.t1' are valid extensions, while `.x-y',
`.6c' and `.t.1' are not.

   For tests that match an extension `.EXT' listed in
`TEST_EXTENSIONS', you can provide a test driver using the variable
`EXT_LOG_COMPILER' (note the upper-case extension) and pass options in
`AM_EXT_LOG_FLAGS' and allow the user to pass options in
`EXT_LOG_FLAGS'.  It will cause all tests with this extension to be
called with this driver.  For all tests without a registered extension,
the variables `LOG_COMPILER', `AM_LOG_FLAGS', and `LOG_FLAGS' may be
used.  For example,

     TESTS = foo.pl bar.py baz
     TEST_EXTENSIONS = .pl .py
     PL_LOG_COMPILER = $(PERL)
     AM_PL_LOG_FLAGS = -w
     PY_LOG_COMPILER = $(PYTHON)
     AM_PY_LOG_FLAGS = -v
     LOG_COMPILER = ./wrapper-script
     AM_LOG_FLAGS = -d

will invoke `$(PERL) -w foo.pl', `$(PYTHON) -v bar.py', and
`./wrapper-script -d baz' to produce `foo.log', `bar.log', and
`baz.log', respectively.  The `TESTS_ENVIRONMENT' variable is still
expanded before the driver, but should be reserved for the user.

   As with the simple driver above, by default one status line is
printed per completed test, and a short summary after the suite has
completed.  However, standard output and standard error of the test are
redirected to a per-test log file, so that parallel execution does not
produce intermingled output.  The output from failed tests is collected
in the `test-suite.log' file.  If the variable `VERBOSE' is set, this
file is output after the summary.  For best results, the tests should be
verbose by default now.

   With `make check-html', the log files may be converted from RST
(reStructuredText, see `http://docutils.sourceforge.net/rst.html') to
HTML using `RST2HTML', which defaults to `rst2html' or `rst2html.py'.
The variable `TEST_SUITE_HTML' contains the set of converted log files.
The log and HTML files are removed upon `make mostlyclean'.

   Even in the presence of expected failures (see `XFAIL_TESTS'), there
may be conditions under which a test outcome needs attention.  For
example, with test-driven development, you may write tests for features
that you have not implemented yet, and thus mark these tests as expected
to fail.  However, you may still be interested in exceptional
conditions, for example, tests that fail due to a segmentation
violation or another error that is independent of the feature awaiting
implementation.  Tests can exit with an exit status of 99 to signal
such a _hard error_.  Unless the variable `DISABLE_HARD_ERRORS' is set
to a nonempty value, such tests will be counted as failed.

   By default, the test suite driver will run all tests, but there are
several ways to limit the set of tests that are run:

   * You can set the `TESTS' variable, similarly to how you can with
     the simple test driver from the previous section.  For example,
     you can use a command like this to run only a subset of the tests:

          env TESTS="foo.test bar.test" make -e check

     Note however that the command above will unconditionally overwrite
     the `test-suite.log' file, thus clobbering the recorded results of
     any previous testsuite run.  This might be undesirable for packages
     whose testsuite takes long time to execute.  Luckily, this problem
     can easily be avoided by overriding also `TEST_SUITE_LOG' at
     runtime; for example,

          env TEST_SUITE_LOG=partial.log TESTS="..." make -e check

     will write the result of the partial testsuite runs to the
     `partial.log', without touching `test-suite.log'.

   * You can set the `TEST_LOGS' variable.  By default, this variable is
     computed at `make' run time from the value of `TESTS' as described
     above.  For example, you can use the following:

          set x subset*.log; shift
          env TEST_LOGS="foo.log $*" make -e check

     The comments made above about `TEST_SUITE_LOG' overriding applies
     here too.

   * By default, the test driver removes all old per-test log files
     before it starts running tests to regenerate them.  The variable
     `RECHECK_LOGS' contains the set of log files which are removed.
     `RECHECK_LOGS' defaults to `TEST_LOGS', which means all tests need
     to be rechecked.  By overriding this variable, you can choose which
     tests need to be reconsidered.  For example, you can lazily rerun
     only those tests which are outdated, i.e., older than their
     prerequisite test files, by setting this variable to the empty
     value:

          env RECHECK_LOGS= make -e check

   * You can ensure that all tests are rerun which have failed or passed
     unexpectedly, by running `make recheck' in the test directory.
     This convenience target will set `RECHECK_LOGS' appropriately
     before invoking the main test driver.  The `recheck-html' target
     does the same as `recheck' but again converts the resulting log
     file in HTML format, like the `check-html' target.

   In order to guarantee an ordering between tests even with `make
-jN', dependencies between the corresponding log files may be specified
through usual `make' dependencies.  For example, the following snippet
lets the test named `foo-execute.test' depend upon completion of the
test `foo-compile.test':

     TESTS = foo-compile.test foo-execute.test
     foo-execute.log: foo-compile.log

Please note that this ordering ignores the _results_ of required tests,
thus the test `foo-execute.test' is run even if the test
`foo-compile.test' failed or was skipped beforehand.  Further, please
note that specifying such dependencies currently works only for tests
that end in one of the suffixes listed in `TEST_EXTENSIONS'.

   Tests without such specified dependencies may be run concurrently
with parallel `make -jN', so be sure they are prepared for concurrent
execution.

   The combination of lazy test execution and correct dependencies
between tests and their sources may be exploited for efficient unit
testing during development.  To further speed up the edit-compile-test
cycle, it may even be useful to specify compiled programs in
`EXTRA_PROGRAMS' instead of with `check_PROGRAMS', as the former allows
intertwined compilation and test execution (but note that
`EXTRA_PROGRAMS' are not cleaned automatically, *note Uniform::).

   The variables `TESTS' and `XFAIL_TESTS' may contain conditional
parts as well as configure substitutions.  In the latter case, however,
certain restrictions apply: substituted test names must end with a
nonempty test suffix like `.test', so that one of the inference rules
generated by `automake' can apply.  For literal test names, `automake'
can generate per-target rules to avoid this limitation.

   Please note that it is currently not possible to use `$(srcdir)/' or
`$(top_srcdir)/' in the `TESTS' variable.  This technical limitation is
necessary to avoid generating test logs in the source tree and has the
unfortunate consequence that it is not possible to specify distributed
tests that are themselves generated by means of explicit rules, in a
way that is portable to all `make' implementations (*note Make Target
Lookup: (autoconf)Make Target Lookup, the semantics of FreeBSD and
OpenBSD `make' conflict with this).  In case of doubt you may want to
require to use GNU `make', or work around the issue with inference
rules to generate the tests.


File: automake.info,  Node: DejaGnu Tests,  Next: Install Tests,  Prev: Simple Tests using parallel-tests,  Up: Tests

15.3 DejaGnu Tests
==================

If `dejagnu' (ftp://ftp.gnu.org/gnu/dejagnu/) appears in
`AUTOMAKE_OPTIONS', then a `dejagnu'-based test suite is assumed.  The
variable `DEJATOOL' is a list of names that are passed, one at a time,
as the `--tool' argument to `runtest' invocations; it defaults to the
name of the package.

   The variable `RUNTESTDEFAULTFLAGS' holds the `--tool' and `--srcdir'
flags that are passed to dejagnu by default; this can be overridden if
necessary.  

   The variables `EXPECT' and `RUNTEST' can also be overridden to
provide project-specific values.  For instance, you will need to do
this if you are testing a compiler toolchain, because the default
values do not take into account host and target names.  

   The contents of the variable `RUNTESTFLAGS' are passed to the
`runtest' invocation.  This is considered a "user variable" (*note User
Variables::).  If you need to set `runtest' flags in `Makefile.am', you
can use `AM_RUNTESTFLAGS' instead.  

   Automake will generate rules to create a local `site.exp' file,
defining various variables detected by `configure'.  This file is
automatically read by DejaGnu.  It is OK for the user of a package to
edit this file in order to tune the test suite.  However this is not
the place where the test suite author should define new variables: this
should be done elsewhere in the real test suite code.  Especially,
`site.exp' should not be distributed.

   Still, if the package author has legitimate reasons to extend
`site.exp' at `make' time, he can do so by defining the variable
`EXTRA_DEJAGNU_SITE_CONFIG'; the files listed there will be considered
`site.exp' prerequisites, and their content will be appended to it (in
the same order in which they appear in `EXTRA_DEJAGNU_SITE_CONFIG').
Note that files are _not_ distributed by default.

   For more information regarding DejaGnu test suites, see *note Top:
(dejagnu)Top.

   In either case, the testing is done via `make check'.


File: automake.info,  Node: Install Tests,  Prev: DejaGnu Tests,  Up: Tests

15.4 Install Tests
==================

The `installcheck' target is available to the user as a way to run any
tests after the package has been installed.  You can add tests to this
by writing an `installcheck-local' rule.


File: automake.info,  Node: Rebuilding,  Next: Options,  Prev: Tests,  Up: Top

16 Rebuilding Makefiles
***********************

Automake generates rules to automatically rebuild `Makefile's,
`configure', and other derived files like `Makefile.in'.

   If you are using `AM_MAINTAINER_MODE' in `configure.ac', then these
automatic rebuilding rules are only enabled in maintainer mode.

   Sometimes you need to run `aclocal' with an argument like `-I' to
tell it where to find `.m4' files.  Since sometimes `make' will
automatically run `aclocal', you need a way to specify these arguments.
You can do this by defining `ACLOCAL_AMFLAGS'; this holds arguments
that are passed verbatim to `aclocal'.  This variable is only useful in
the top-level `Makefile.am'.

   Sometimes it is convenient to supplement the rebuild rules for
`configure' or `config.status' with additional dependencies.  The
variables `CONFIGURE_DEPENDENCIES' and `CONFIG_STATUS_DEPENDENCIES' can
be used to list these extra dependencies.  These variables should be
defined in all `Makefile's of the tree (because these two rebuild rules
are output in all them), so it is safer and easier to `AC_SUBST' them
from `configure.ac'.  For instance, the following statement will cause
`configure' to be rerun each time `version.sh' is changed.

     AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version.sh'])

Note the `$(top_srcdir)/' in the file name.  Since this variable is to
be used in all `Makefile's, its value must be sensible at any level in
the build hierarchy.

   Beware not to mistake `CONFIGURE_DEPENDENCIES' for
`CONFIG_STATUS_DEPENDENCIES'.

   `CONFIGURE_DEPENDENCIES' adds dependencies to the `configure' rule,
whose effect is to run `autoconf'.  This variable should be seldom
used, because `automake' already tracks `m4_include'd files.  However
it can be useful when playing tricky games with `m4_esyscmd' or similar
non-recommendable macros with side effects.

   `CONFIG_STATUS_DEPENDENCIES' adds dependencies to the
`config.status' rule, whose effect is to run `configure'.  This
variable should therefore carry any non-standard source that may be
read as a side effect of running `configure', like `version.sh' in the
example above.

   Speaking of `version.sh' scripts, we recommend against them today.
They are mainly used when the version of a package is updated
automatically by a script (e.g., in daily builds).  Here is what some
old-style `configure.ac's may look like:

     AC_INIT
     . $srcdir/version.sh
     AM_INIT_AUTOMAKE([name], $VERSION_NUMBER)
     ...

Here, `version.sh' is a shell fragment that sets `VERSION_NUMBER'.  The
problem with this example is that `automake' cannot track dependencies
(listing `version.sh' in `CONFIG_STATUS_DEPENDENCIES', and distributing
this file is up to the user), and that it uses the obsolete form of
`AC_INIT' and `AM_INIT_AUTOMAKE'.  Upgrading to the new syntax is not
straightforward, because shell variables are not allowed in `AC_INIT''s
arguments.  We recommend that `version.sh' be replaced by an M4 file
that is included by `configure.ac':

     m4_include([version.m4])
     AC_INIT([name], VERSION_NUMBER)
     AM_INIT_AUTOMAKE
     ...

Here `version.m4' could contain something like
`m4_define([VERSION_NUMBER], [1.2])'.  The advantage of this second
form is that `automake' will take care of the dependencies when
defining the rebuild rule, and will also distribute the file
automatically.  An inconvenience is that `autoconf' will now be rerun
each time the version number is bumped, when only `configure' had to be
rerun in the previous setup.


File: automake.info,  Node: Options,  Next: Miscellaneous,  Prev: Rebuilding,  Up: Top

17 Changing Automake's Behavior
*******************************

Various features of Automake can be controlled by options.  Except where
noted otherwise, options can be specified in one of several ways: Most
options can be applied on a per-`Makefile' basis when listed in a
special `Makefile' variable named `AUTOMAKE_OPTIONS'.  Some of these
options only make sense when specified in the toplevel `Makefile.am'
file.  Options are applied globally to all processed `Makefile' files
when listed in the first argument of `AM_INIT_AUTOMAKE' in
`configure.ac', and some options which require changes to the
`configure' script can only be specified there.  These are annotated
below.

   Currently understood options are: 

`gnits'
`gnu'
`foreign'
`cygnus'
     Set the strictness as appropriate.  The `gnits' option also
     implies options `readme-alpha' and `check-news'.

`ansi2knr'
`PATH/ansi2knr'
     Turn on the deprecated de-ANSI-fication feature (*note ANSI::).
     Note that that feature and this option _will be removed_ in the
     next major Automake release.

     If preceded by a path, the generated `Makefile.in' will look in
     the specified directory to find the `ansi2knr' program.  The path
     should be a relative path to another directory in the same
     distribution (Automake does not check this).

`check-news'
     Cause `make dist' to fail unless the current version number appears
     in the first few lines of the `NEWS' file.

`color-tests'
     Cause output of the simple test suite (*note Simple Tests::) to be
     colorized on capable terminals.

`dejagnu'
     Cause `dejagnu'-specific rules to be generated.  *Note DejaGnu
     Tests::.

`dist-bzip2'
     Hook `dist-bzip2' to `dist'.  

`dist-lzma'
     Hook `dist-lzma' to `dist'.  Obsoleted by `dist-xz'.  

`dist-shar'
     Hook `dist-shar' to `dist'.  

`dist-zip'
     Hook `dist-zip' to `dist'.  

`dist-tarZ'
     Hook `dist-tarZ' to `dist'.  

`filename-length-max=99'
     Abort if file names longer than 99 characters are found during
     `make dist'.  Such long file names are generally considered not to
     be portable in tarballs.  See the `tar-v7' and `tar-ustar' options
     below.  This option should be used in the top-level `Makefile.am'
     or as an argument of `AM_INIT_AUTOMAKE' in `configure.ac', it will
     be ignored otherwise.  It will also be ignored in sub-packages of
     nested packages (*note Subpackages::).

`no-define'
     This option is meaningful only when passed as an argument to
     `AM_INIT_AUTOMAKE'.  It will prevent the `PACKAGE' and `VERSION'
     variables from being `AC_DEFINE'd.

`no-dependencies'
     This is similar to using `--ignore-deps' on the command line, but
     is useful for those situations where you don't have the necessary
     bits to make automatic dependency tracking work (*note
     Dependencies::).  In this case the effect is to effectively
     disable automatic dependency tracking.

`no-dist'
     Don't emit any code related to `dist' target.  This is useful when
     a package has its own method for making distributions.

`no-dist-gzip'
     Do not hook `dist-gzip' to `dist'.  

`no-exeext'
     If your `Makefile.am' defines a rule for target `foo', it will
     override a rule for a target named `foo$(EXEEXT)'.  This is
     necessary when `EXEEXT' is found to be empty.  However, by default
     `automake' will generate an error for this use.  The `no-exeext'
     option will disable this error.  This is intended for use only
     where it is known in advance that the package will not be ported
     to Windows, or any other operating system using extensions on
     executables.

`no-installinfo'
     The generated `Makefile.in' will not cause info pages to be built
     or installed by default.  However, `info' and `install-info'
     targets will still be available.  This option is disallowed at
     `gnu' strictness and above.  

`no-installman'
     The generated `Makefile.in' will not cause man pages to be
     installed by default.  However, an `install-man' target will still
     be available for optional installation.  This option is disallowed
     at `gnu' strictness and above.  

`nostdinc'
     This option can be used to disable the standard `-I' options that
     are ordinarily automatically provided by Automake.

`no-texinfo.tex'
     Don't require `texinfo.tex', even if there are texinfo files in
     this directory.

`parallel-tests'
     Enable test suite driver for `TESTS' that can run tests in parallel
     (*note Simple Tests using parallel-tests::, for more information).

`readme-alpha'
     If this release is an alpha release, and the file `README-alpha'
     exists, then it will be added to the distribution.  If this option
     is given, version numbers are expected to follow one of two forms.
     The first form is `MAJOR.MINOR.ALPHA', where each element is a
     number; the final period and number should be left off for
     non-alpha releases.  The second form is `MAJOR.MINORALPHA', where
     ALPHA is a letter; it should be omitted for non-alpha releases.

`silent-rules'
     Enable less verbose build rules.  This can be used to let build
     rules output status lines of the form:
          GEN OUTPUT-FILE
           CC OBJECT-FILE
     instead of printing the command that will be executed to update
     OUTPUT-FILE or to compile OBJECT-FILE.  It can also silence
     `libtool' output.

     For more information about how to use, enable, or disable silent
     rules, *note Automake silent-rules Option::.

`std-options'
     Make the `installcheck' rule check that installed scripts and
     programs support the `--help' and `--version' options.  This also
     provides a basic check that the program's run-time dependencies
     are satisfied after installation.

     In a few situations, programs (or scripts) have to be exempted
     from this test.  For instance, `false' (from GNU coreutils) is
     never successful, even for `--help' or `--version'.  You can list
     such programs in the variable `AM_INSTALLCHECK_STD_OPTIONS_EXEMPT'.
     Programs (not scripts) listed in this variable should be suffixed
     by `$(EXEEXT)' for the sake of Win32 or OS/2.  For instance,
     suppose we build `false' as a program but `true.sh' as a script,
     and that neither of them support `--help' or `--version':

          AUTOMAKE_OPTIONS = std-options
          bin_PROGRAMS = false ...
          bin_SCRIPTS = true.sh ...
          AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = false$(EXEEXT) true.sh

`subdir-objects'
     If this option is specified, then objects are placed into the
     subdirectory of the build directory corresponding to the
     subdirectory of the source file.  For instance, if the source file
     is `subdir/file.cxx', then the output file would be
     `subdir/file.o'.

     In order to use this option with C sources, you should add
     `AM_PROG_CC_C_O' to `configure.ac'.

`tar-v7'
`tar-ustar'
`tar-pax'
     These three mutually exclusive options select the tar format to use
     when generating tarballs with `make dist'.  (The tar file created
     is then compressed according to the set of `no-dist-gzip',
     `dist-bzip2', `dist-xz' and `dist-tarZ' options in use.)

     These options must be passed as arguments to `AM_INIT_AUTOMAKE'
     (*note Macros::) because they can require additional configure
     checks.  Automake will complain if it sees such options in an
     `AUTOMAKE_OPTIONS' variable.

     `tar-v7' selects the old V7 tar format.  This is the historical
     default.  This antiquated format is understood by all tar
     implementations and supports file names with up to 99 characters.
     When given longer file names some tar implementations will
     diagnose the problem while other will generate broken tarballs or
     use non-portable extensions.  Furthermore, the V7 format cannot
     store empty directories.  When using this format, consider using
     the `filename-length-max=99' option to catch file names too long.

     `tar-ustar' selects the ustar format defined by POSIX 1003.1-1988.
     This format is believed to be old enough to be portable.  It fully
     supports empty directories.  It can store file names with up to
     256 characters, provided that the file name can be split at
     directory separator in two parts, first of them being at most 155
     bytes long.  So, in most cases the maximum file name length will be
     shorter than 256 characters.  However you may run against broken
     tar implementations that incorrectly handle file names longer than
     99 characters (please report them to <bug-automake@gnu.org> so we
     can document this accurately).

     `tar-pax' selects the new pax interchange format defined by POSIX
     1003.1-2001.  It does not limit the length of file names.  However,
     this format is very young and should probably be restricted to
     packages that target only very modern platforms.  There are moves
     to change the pax format in an upward-compatible way, so this
     option may refer to a more recent version in the future.

     *Note Controlling the Archive Format: (tar)Formats, for further
     discussion about tar formats.

     `configure' knows several ways to construct these formats.  It
     will not abort if it cannot find a tool up to the task (so that the
     package can still be built), but `make dist' will fail.

VERSION
     A version number (e.g., `0.30') can be specified.  If Automake is
     not newer than the version specified, creation of the `Makefile.in'
     will be suppressed.

`-WCATEGORY' or `--warnings=CATEGORY'
     These options behave exactly like their command-line counterpart
     (*note Invoking Automake::).  This allows you to enable or disable
     some warning categories on a per-file basis.  You can also setup
     some warnings for your entire project; for instance, try
     `AM_INIT_AUTOMAKE([-Wall])' in your `configure.ac'.


   Unrecognized options are diagnosed by `automake'.

   If you want an option to apply to all the files in the tree, you can
use the `AM_INIT_AUTOMAKE' macro in `configure.ac'.  *Note Macros::.


File: automake.info,  Node: Miscellaneous,  Next: Include,  Prev: Options,  Up: Top

18 Miscellaneous Rules
**********************

There are a few rules and variables that didn't fit anywhere else.

* Menu:

* Tags::                        Interfacing to etags and mkid
* Suffixes::                    Handling new file extensions
* Multilibs::                   Support for multilibs.


File: automake.info,  Node: Tags,  Next: Suffixes,  Up: Miscellaneous

18.1 Interfacing to `etags'
===========================

Automake will generate rules to generate `TAGS' files for use with GNU
Emacs under some circumstances.

   If any C, C++ or Fortran 77 source code or headers are present, then
`tags' and `TAGS' rules will be generated for the directory.  All files
listed using the `_SOURCES', `_HEADERS', and `_LISP' primaries will be
used to generate tags.  Note that generated source files that are not
distributed must be declared in variables like `nodist_noinst_HEADERS'
or `nodist_PROG_SOURCES' or they will be ignored.

   A `tags' rule will be output at the topmost directory of a
multi-directory package.  When run from this topmost directory, `make
tags' will generate a `TAGS' file that includes by reference all `TAGS'
files from subdirectories.

   The `tags' rule will also be generated if the variable `ETAGS_ARGS'
is defined.  This variable is intended for use in directories that
contain taggable source that `etags' does not understand.  The user can
use the `ETAGSFLAGS' to pass additional flags to `etags';
`AM_ETAGSFLAGS' is also available for use in `Makefile.am'.  

   Here is how Automake generates tags for its source, and for nodes in
its Texinfo file:

     ETAGS_ARGS = automake.in --lang=none \
      --regex='/^@node[ \t]+\([^,]+\)/\1/' automake.texi

   If you add file names to `ETAGS_ARGS', you will probably also want
to define `TAGS_DEPENDENCIES'.  The contents of this variable are added
directly to the dependencies for the `tags' rule.  

   Automake also generates a `ctags' rule that can be used to build
`vi'-style `tags' files.  The variable `CTAGS' is the name of the
program to invoke (by default `ctags'); `CTAGSFLAGS' can be used by the
user to pass additional flags, and `AM_CTAGSFLAGS' can be used by the
`Makefile.am'.

   Automake will also generate an `ID' rule that will run `mkid' on the
source.  This is only supported on a directory-by-directory basis.  

   Finally, Automake also emits rules to support the GNU Global Tags
program (http://www.gnu.org/software/global/).  The `GTAGS' rule runs
Global Tags and puts the result in the top build directory.  The
variable `GTAGS_ARGS' holds arguments that are passed to `gtags'.  


File: automake.info,  Node: Suffixes,  Next: Multilibs,  Prev: Tags,  Up: Miscellaneous

18.2 Handling new file extensions
=================================

It is sometimes useful to introduce a new implicit rule to handle a file
type that Automake does not know about.

   For instance, suppose you had a compiler that could compile `.foo'
files to `.o' files.  You would simply define a suffix rule for your
language:

     .foo.o:
             foocc -c -o $@ $<

   Then you could directly use a `.foo' file in a `_SOURCES' variable
and expect the correct results:

     bin_PROGRAMS = doit
     doit_SOURCES = doit.foo

   This was the simpler and more common case.  In other cases, you will
have to help Automake to figure out which extensions you are defining
your suffix rule for.  This usually happens when your extension does not
start with a dot.  Then, all you have to do is to put a list of new
suffixes in the `SUFFIXES' variable *before* you define your implicit
rule.

   For instance, the following definition prevents Automake from
misinterpreting the `.idlC.cpp:' rule as an attempt to transform
`.idlC' files into `.cpp' files.

     SUFFIXES = .idl C.cpp
     .idlC.cpp:
             # whatever

   As you may have noted, the `SUFFIXES' variable behaves like the
`.SUFFIXES' special target of `make'.  You should not touch `.SUFFIXES'
yourself, but use `SUFFIXES' instead and let Automake generate the
suffix list for `.SUFFIXES'.  Any given `SUFFIXES' go at the start of
the generated suffixes list, followed by Automake generated suffixes
not already in the list.


File: automake.info,  Node: Multilibs,  Prev: Suffixes,  Up: Miscellaneous

18.3 Support for Multilibs
==========================

Automake has support for an obscure feature called multilibs.  A
"multilib" is a library that is built for multiple different ABIs at a
single time; each time the library is built with a different target
flag combination.  This is only useful when the library is intended to
be cross-compiled, and it is almost exclusively used for compiler
support libraries.

   The multilib support is still experimental.  Only use it if you are
familiar with multilibs and can debug problems you might encounter.


File: automake.info,  Node: Include,  Next: Conditionals,  Prev: Miscellaneous,  Up: Top

19 Include
**********

Automake supports an `include' directive that  can be used to include
other `Makefile' fragments when `automake' is run.  Note that these
fragments are read and interpreted by `automake', not by `make'.  As
with conditionals, `make' has no idea that `include' is in use.

   There are two forms of `include':

`include $(srcdir)/file'
     Include a fragment that is found relative to the current source
     directory.

`include $(top_srcdir)/file'
     Include a fragment that is found relative to the top source
     directory.

   Note that if a fragment is included inside a conditional, then the
condition applies to the entire contents of that fragment.

   Makefile fragments included this way are always distributed because
they are needed to rebuild `Makefile.in'.


File: automake.info,  Node: Conditionals,  Next: Silencing Make,  Prev: Include,  Up: Top

20 Conditionals
***************

Automake supports a simple type of conditionals.

   These conditionals are not the same as conditionals in GNU Make.
Automake conditionals are checked at configure time by the `configure'
script, and affect the translation from `Makefile.in' to `Makefile'.
They are based on options passed to `configure' and on results that
`configure' has discovered about the host system.  GNU Make
conditionals are checked at `make' time, and are based on variables
passed to the make program or defined in the `Makefile'.

   Automake conditionals will work with any make program.

* Menu:

* Usage of Conditionals::       Declaring conditional content
* Limits of Conditionals::      Enclosing complete statements


File: automake.info,  Node: Usage of Conditionals,  Next: Limits of Conditionals,  Up: Conditionals

20.1 Usage of Conditionals
==========================

Before using a conditional, you must define it by using
`AM_CONDITIONAL' in the `configure.ac' file (*note Macros::).

 -- Macro: AM_CONDITIONAL (CONDITIONAL, CONDITION)
     The conditional name, CONDITIONAL, should be a simple string
     starting with a letter and containing only letters, digits, and
     underscores.  It must be different from `TRUE' and `FALSE' that
     are reserved by Automake.

     The shell CONDITION (suitable for use in a shell `if' statement)
     is evaluated when `configure' is run.  Note that you must arrange
     for _every_ `AM_CONDITIONAL' to be invoked every time `configure'
     is run.  If `AM_CONDITIONAL' is run conditionally (e.g., in a
     shell `if' statement), then the result will confuse `automake'.

   Conditionals typically depend upon options that the user provides to
the `configure' script.  Here is an example of how to write a
conditional that is true if the user uses the `--enable-debug' option.

     AC_ARG_ENABLE([debug],
     [  --enable-debug    Turn on debugging],
     [case "${enableval}" in
       yes) debug=true ;;
       no)  debug=false ;;
       *) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
     esac],[debug=false])
     AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])

   Here is an example of how to use that conditional in `Makefile.am':

     if DEBUG
     DBG = debug
     else
     DBG =
     endif
     noinst_PROGRAMS = $(DBG)

   This trivial example could also be handled using `EXTRA_PROGRAMS'
(*note Conditional Programs::).

   You may only test a single variable in an `if' statement, possibly
negated using `!'.  The `else' statement may be omitted.  Conditionals
may be nested to any depth.  You may specify an argument to `else' in
which case it must be the negation of the condition used for the
current `if'.  Similarly you may specify the condition that is closed
on the `endif' line:

     if DEBUG
     DBG = debug
     else !DEBUG
     DBG =
     endif !DEBUG

Unbalanced conditions are errors.  The `if', `else', and `endif'
statements should not be indented, i.e., start on column one.

   The `else' branch of the above two examples could be omitted, since
assigning the empty string to an otherwise undefined variable makes no
difference.

   In order to allow access to the condition registered by
`AM_CONDITIONAL' inside `configure.ac', and to allow conditional
`AC_CONFIG_FILES', `AM_COND_IF' may be used:

 -- Macro: AM_COND_IF (CONDITIONAL, [IF-TRUE], [IF-FALSE])
     If CONDITIONAL is fulfilled, execute IF-TRUE, otherwise execute
     IF-FALSE.  If either branch contains `AC_CONFIG_FILES', it will
     cause `automake' to output the rules for the respective files only
     for the given condition.

   `AM_COND_IF' macros may be nested when m4 quotation is used properly
(*note M4 Quotation: (autoconf)M4 Quotation.).

   Here is an example of how to define a conditional config file:

     AM_CONDITIONAL([SHELL_WRAPPER], [test "x$with_wrapper" = xtrue])
     AM_COND_IF([SHELL_WRAPPER],
                [AC_CONFIG_FILES([wrapper:wrapper.in])])


File: automake.info,  Node: Limits of Conditionals,  Prev: Usage of Conditionals,  Up: Conditionals

20.2 Limits of Conditionals
===========================

Conditionals should enclose complete statements like variables or rules
definitions.  Automake cannot deal with conditionals used inside a
variable definition, for instance, and is not even able to diagnose
this situation.  The following example would not work:

     # This syntax is not understood by Automake
     AM_CPPFLAGS = \
       -DFEATURE_A \
     if WANT_DEBUG
       -DDEBUG \
     endif
       -DFEATURE_B

   However the intended definition of `AM_CPPFLAGS' can be achieved with

     if WANT_DEBUG
       DEBUGFLAGS = -DDEBUG
     endif
     AM_CPPFLAGS = -DFEATURE_A $(DEBUGFLAGS) -DFEATURE_B

or

     AM_CPPFLAGS = -DFEATURE_A
     if WANT_DEBUG
     AM_CPPFLAGS += -DDEBUG
     endif
     AM_CPPFLAGS += -DFEATURE_B

   More details and examples of conditionals are described alongside
various Automake features in this manual (*note Conditional
Subdirectories::, *note Conditional Sources::, *note Conditional
Programs::, *note Conditional Libtool Libraries::, *note Conditional
Libtool Sources::).


File: automake.info,  Node: Silencing Make,  Next: Gnits,  Prev: Conditionals,  Up: Top

21 Silencing `make'
*******************

* Menu:

* Make verbosity::               Make is verbose by default
* Tricks For Silencing Make::    Standard and generic ways to silence make
* Automake silent-rules Option:: How Automake can help in silencing make


File: automake.info,  Node: Make verbosity,  Next: Tricks For Silencing Make,  Up: Silencing Make

21.1 Make is verbose by default
===============================

Normally, when executing the set of rules associated with a target,
`make' prints each rule before it is executed.  This behaviour, while
having been in place for a long time, and being even mandated by the
POSIX standard, starkly violates the "silence is golden" UNIX
principle(1):

     When a program has nothing interesting or surprising to say, it
     should say nothing.  Well-behaved Unix programs do their jobs
     unobtrusively, with a minimum of fuss and bother.  Silence is
     golden.

   In fact, while such verbosity of `make' can theoretically be useful
to track bugs and understand reasons of failures right away, it can
also hide warning and error messages from `make'-invoked tools,
drowning them in a flood of uninteresting and seldom useful messages,
and thus allowing them to go easily undetected.

   This problem can be very annoying, especially for developers, who
usually know quite well what's going on behind the scenes, and for whom
the verbose output from `make' ends up being mostly noise that hampers
the easy detection of potentially important warning messages.

   ---------- Footnotes ----------

   (1) See also `http://catb.org/~esr/writings/taoup/html/ch11s09.html'.


File: automake.info,  Node: Tricks For Silencing Make,  Next: Automake silent-rules Option,  Prev: Make verbosity,  Up: Silencing Make

21.2 Standard and generic ways to silence make
==============================================

Here we describe some common idioms/tricks to obtain a quieter make
output, with their relative advantages and drawbacks.  In the next
section (*note Automake silent-rules Option::) we'll see how Automake
can help in this respect.

   * `make -s'

     This simply causes `make' not to print _any_ rule before executing
     it.

     The `-s' flag is mandated by POSIX, universally supported, and its
     purpose and function are easy to understand.

     But it also has its serious limitations too.  First of all, it
     embodies an "all or nothing" strategy, i.e., either everything is
     silenced, or nothing is; this lack of granularity can sometimes be
     a fatal flaw.  Moreover, when the `-s' flag is used, the `make'
     output might turn out to be too much terse; in case of errors, the
     user won't be able to easily see what rule or command have caused
     them, or even, in case of tools with poor error reporting, what
     the errors were!

   * `make >/dev/null || make'

     Apparently, this perfectly obeys the "silence is golden" rule:
     warnings from stderr are passed through, output reporting is done
     only in case of error, and in that case it should provide a
     verbose-enough report to allow an easy determination of the error
     location and causes.

     However, calling `make' two times in a row might hide errors
     (especially intermittent ones), or subtly change the expected
     semantic of the `make' calls -- things these which can clearly make
     debugging and error assessment very difficult.

   * `make --no-print-directory'

     This is GNU `make' specific.  When called with the
     `--no-print-directory' option, GNU `make' will disable printing of
     the working directory by invoked sub-`make's (the well-known
     "Entering/Leaving directory ..." messages).  This helps to
     decrease the verbosity of the output, but experience has shown that
     it can also often render debugging considerably harder in projects
     using deeply-nested `make' recursion.

     As an aside, notice that the `--no-print-directory' option is
     automatically activated if the `-s' flag is used.



File: automake.info,  Node: Automake silent-rules Option,  Prev: Tricks For Silencing Make,  Up: Silencing Make

21.3 How Automake can help in silencing make
============================================

The tricks and idioms for silencing `make' described in the previous
section can be useful from time to time, but we've seen that they all
have their serious drawbacks and limitations.  That's why automake
provides support for a more advanced and flexible way of obtaining
quieter output from `make': the `silent-rules' mode.

   To give the gist of what `silent-rules' can do, here is a simple
comparison between a typical `make' output (where silent rules are
disabled) and one with silent rules enabled:

     % cat Makefile.am
     bin_PROGRAMS = foo
     foo_SOURCES = main.c func.c
     % cat main.c
     int main (void) { return func (); }  /* func used undeclared */
     % cat func.c
     int func (void) { int i; return i; } /* i used uninitialized */

     The make output is by default very verbose.  This causes warnings
     from the compiler to be somewhat hidden, and not immediate to spot.
     % make CFLAGS=-Wall
     gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" ...
     -DPACKAGE_STRING=\"foo\ 1.0\" -DPACKAGE_BUGREPORT=\"\" ...
     -DPACKAGE=\"foo\" -DVERSION=\"1.0\" -I. -Wall -MT main.o
     -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
     main.c: In function ‘main’:
     main.c:3:3: warning: implicit declaration of function ‘func’
     mv -f .deps/main.Tpo .deps/main.Po
     gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" ...
     -DPACKAGE_STRING=\"foo\ 1.0\" -DPACKAGE_BUGREPORT=\"\" ...
     -DPACKAGE=\"foo\" -DVERSION=\"1.0\" -I. -Wall -MT func.o
     -MD -MP -MF .deps/func.Tpo -c -o func.o func.c
     func.c: In function ‘func’:
     func.c:4:3: warning: ‘i’ used uninitialized in this function
     mv -f .deps/func.Tpo .deps/func.Po
     gcc -Wall -o foo main.o func.o

     Clean up, so that we we can rebuild everything from scratch.
     % make clean
     test -z "foo" || rm -f foo
     rm -f *.o

     Silent rules enabled: the output is minimal but informative.  In
     particular, the warnings from the compiler stick out very clearly.
     % make V=0 CFLAGS=-Wall
       CC     main.o
     main.c: In function ‘main’:
     main.c:3:3: warning: implicit declaration of function ‘func’
       CC     func.o
     func.c: In function ‘func’:
     func.c:4:3: warning: ‘i’ used uninitialized in this function
       CCLD   foo

   Also, in projects using `libtool', the use of silent rules can
automatically enable the `libtool''s `--silent' option:

     % cat Makefile.am
     lib_LTLIBRARIES = libx.la

     % make # Both make and libtool are verbose by default.
     ...
     libtool: compile: gcc -DPACKAGE_NAME=\"foo\" ... -DLT_OBJDIR=\".libs/\"
       -I. -g -O2 -MT libx.lo -MD -MP -MF .deps/libx.Tpo -c libx.c -fPIC
       -DPIC -o .libs/libx.o
     mv -f .deps/libx.Tpo .deps/libx.Plo
     /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o libx.la -rpath
       /usr/local/lib libx.lo
     libtool: link: gcc -shared .libs/libx.o -Wl,-soname -Wl,libx.so.0
       -o .libs/libx.so.0.0.0
     libtool: link: cd .libs && rm -f libx.so && ln -s libx.so.0.0.0 libx.so
     ...

     % make V=0
       CC     libx.lo
       CCLD   libx.la

   Let's now see how the `silent-rules' mode interfaces with the
package developer and the package user.

   To enable the use of `silent-rules' in his package, a developer
needs to do either of the following:

   * Add the `silent-rules' option as argument to `AM_INIT_AUTOMAKE'.

   * Call the `AM_SILENT_RULES' macro from within the `configure.ac'
     file.

   It is not possible to instead specify `silent-rules' in a
`Makefile.am' file.

   If the developer has done either of the above, then the user of the
package may influence the verbosity at `configure' run time as well as
at `make' run time:

   * Passing `--enable-silent-rules' to `configure' will cause build
     rules to be less verbose; the option `--disable-silent-rules' will
     cause normal verbose output.

   * At `make' run time, the default chosen at `configure' time may be
     overridden: `make V=1' will produce verbose output, `make V=0'
     less verbose output.

   Note that silent rules are _disabled_ by default; the user must
enable them explicitly at either `configure' run time or at `make' run
time.  We think that this is a good policy, since it provides the
casual user with enough information to prepare a good bug report in
case anything breaks.

   Still, notwithstanding the rationales above, a developer who wants to
make silent rules enabled by default in his own package can do so by
adding a `yes' argument to the `AM_SILENT_RULES' call in
`configure.ac'.  We advise against this approach, though.

   Users who prefer to have silent rules enabled by default can edit
their `config.site' file to make the variable `enable_silent_rules'
default to `yes'.  This should still allow disabling silent rules at
`configure' time and at `make' time.

   For portability to different `make' implementations, package authors
are advised to not set the variable `V' inside the `Makefile.am' file,
to allow the user to override the value for subdirectories as well.

   The current implementation of this feature relies on a non-POSIX,
but in practice rather widely supported `Makefile' construct of nested
variable expansion `$(VAR1$(V))'.  Do not use the `silent-rules' option
if your package needs to build with `make' implementations that do not
support it.  The `silent-rules' option turns off warnings about
recursive variable expansion, which are in turn enabled by
`-Wportability' (*note Invoking Automake::).

   To extend the silent mode to your own rules, you have two choices:

   * You can use the predefined variable `AM_V_GEN' as a prefix to
     commands that should output a status line in silent mode, and
     `AM_V_at' as a prefix to commands that should not output anything
     in silent mode.  When output is to be verbose, both of these
     variables will expand to the empty string.

   * You can add your own variables, so strings of your own choice are
     shown.  The following snippet shows how you would define your own
     equivalent of `AM_V_GEN':

          pkg_verbose = $(pkg_verbose_$(V))
          pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
          pkg_verbose_0 = @echo PKG-GEN $@;

          foo: foo.in
                  $(pkg_verbose)cp $(srcdir)/foo.in $@


   As a final note, observe that, even when silent rules are enabled,
the `--no-print-directory' option is still required with GNU `make' if
the "Entering/Leaving directory ..." messages are to be disabled.


File: automake.info,  Node: Gnits,  Next: Cygnus,  Prev: Silencing Make,  Up: Top

22 The effect of `--gnu' and `--gnits'
**************************************

The `--gnu' option (or `gnu' in the `AUTOMAKE_OPTIONS' variable) causes
`automake' to check the following:

   * The files `INSTALL', `NEWS', `README', `AUTHORS', and `ChangeLog',
     plus one of `COPYING.LIB', `COPYING.LESSER' or `COPYING', are
     required at the topmost directory of the package.

     If the `--add-missing' option is given, `automake' will add a
     generic version of the `INSTALL' file as well as the `COPYING'
     file containing the text of the current version of the GNU General
     Public License existing at the time of this Automake release
     (version 3 as this is written,
     `http://www.gnu.org/copyleft/gpl.html').  However, an existing
     `COPYING' file will never be overwritten by `automake'.

   * The options `no-installman' and `no-installinfo' are prohibited.

   Note that this option will be extended in the future to do even more
checking; it is advisable to be familiar with the precise requirements
of the GNU standards.  Also, `--gnu' can require certain non-standard
GNU programs to exist for use by various maintainer-only rules; for
instance, in the future `pathchk' might be required for `make dist'.

   The `--gnits' option does everything that `--gnu' does, and checks
the following as well:

   * `make installcheck' will check to make sure that the `--help' and
     `--version' really print a usage message and a version string,
     respectively.  This is the `std-options' option (*note Options::).

   * `make dist' will check to make sure the `NEWS' file has been
     updated to the current version.

   * `VERSION' is checked to make sure its format complies with Gnits
     standards.

   * If `VERSION' indicates that this is an alpha release, and the file
     `README-alpha' appears in the topmost directory of a package, then
     it is included in the distribution.  This is done in `--gnits'
     mode, and no other, because this mode is the only one where version
     number formats are constrained, and hence the only mode where
     Automake can automatically determine whether `README-alpha' should
     be included.

   * The file `THANKS' is required.


File: automake.info,  Node: Cygnus,  Next: Not Enough,  Prev: Gnits,  Up: Top

23 The effect of `--cygnus'
***************************

Some packages, notably GNU GCC and GNU gdb, have a build environment
originally written at Cygnus Support (subsequently renamed Cygnus
Solutions, and then later purchased by Red Hat).  Packages with this
ancestry are sometimes referred to as "Cygnus" trees.

   A Cygnus tree has slightly different rules for how a `Makefile.in'
is to be constructed.  Passing `--cygnus' to `automake' will cause any
generated `Makefile.in' to comply with Cygnus rules.

   Here are the precise effects of `--cygnus':

   * Info files are always created in the build directory, and not in
     the source directory.

   * `texinfo.tex' is not required if a Texinfo source file is
     specified.  The assumption is that the file will be supplied, but
     in a place that Automake cannot find.  This assumption is an
     artifact of how Cygnus packages are typically bundled.

   * `make dist' is not supported, and the rules for it are not
     generated.  Cygnus-style trees use their own distribution
     mechanism.

   * Certain tools will be searched for in the build tree as well as in
     the user's `PATH'.  These tools are `runtest', `expect',
     `makeinfo' and `texi2dvi'.

   * `--foreign' is implied.

   * The options `no-installinfo' and `no-dependencies' are implied.

   * The macro `AM_MAINTAINER_MODE' is required.

   * The `check' target doesn't depend on `all'.

   GNU maintainers are advised to use `gnu' strictness in preference to
the special Cygnus mode.  Some day, perhaps, the differences between
Cygnus trees and GNU trees will disappear (for instance, as GCC is made
more standards compliant).  At that time the special Cygnus mode will be
removed.


File: automake.info,  Node: Not Enough,  Next: Distributing,  Prev: Cygnus,  Up: Top

24 When Automake Isn't Enough
*****************************

In some situations, where Automake is not up to one task, one has to
resort to handwritten rules or even handwritten `Makefile's.

* Menu:

* Extending::                   Adding new rules or overriding existing ones.
* Third-Party Makefiles::       Integrating Non-Automake `Makefile's.


File: automake.info,  Node: Extending,  Next: Third-Party Makefiles,  Up: Not Enough

24.1 Extending Automake Rules
=============================

With some minor exceptions (for example `_PROGRAMS' variables, `TESTS',
or `XFAIL_TESTS') being rewritten to append `$(EXEEXT)'), the contents
of a `Makefile.am' is copied to `Makefile.in' verbatim.

   These copying semantics mean that many problems can be worked around
by simply adding some `make' variables and rules to `Makefile.am'.
Automake will ignore these additions.

   Since a `Makefile.in' is built from data gathered from three
different places (`Makefile.am', `configure.ac', and `automake'
itself), it is possible to have conflicting definitions of rules or
variables.  When building `Makefile.in' the following priorities are
respected by `automake' to ensure the user always has the last word:

   * User defined variables in `Makefile.am' have priority over
     variables `AC_SUBST'ed from `configure.ac', and `AC_SUBST'ed
     variables have priority over `automake'-defined variables.

   * As far as rules are concerned, a user-defined rule overrides any
     `automake'-defined rule for the same target.

   These overriding semantics make it possible to fine tune some default
settings of Automake, or replace some of its rules.  Overriding
Automake rules is often inadvisable, particularly in the topmost
directory of a package with subdirectories.  The `-Woverride' option
(*note Invoking Automake::) comes in handy to catch overridden
definitions.

   Note that Automake does not make any distinction between rules with
commands and rules that only specify dependencies.  So it is not
possible to append new dependencies to an `automake'-defined target
without redefining the entire rule.

   However, various useful targets have a `-local' version you can
specify in your `Makefile.am'.  Automake will supplement the standard
target with these user-supplied targets.

   The targets that support a local version are `all', `info', `dvi',
`ps', `pdf', `html', `check', `install-data', `install-dvi',
`install-exec', `install-html', `install-info', `install-pdf',
`install-ps', `uninstall', `installdirs', `installcheck' and the
various `clean' targets (`mostlyclean', `clean', `distclean', and
`maintainer-clean').

   Note that there are no `uninstall-exec-local' or
`uninstall-data-local' targets; just use `uninstall-local'.  It doesn't
make sense to uninstall just data or just executables.

   For instance, here is one way to erase a subdirectory during `make
clean' (*note Clean::).

     clean-local:
             -rm -rf testSubDir

   You may be tempted to use `install-data-local' to install a file to
some hard-coded location, but you should avoid this (*note Hard-Coded
Install Paths::).

   With the `-local' targets, there is no particular guarantee of
execution order; typically, they are run early, but with parallel make,
there is no way to be sure of that.

   In contrast, some rules also have a way to run another rule, called a
"hook"; hooks are always executed after the main rule's work is done.
The hook is named after the principal target, with `-hook' appended.
The targets allowing hooks are `install-data', `install-exec',
`uninstall', `dist', and `distcheck'.

   For instance, here is how to create a hard link to an installed
program:

     install-exec-hook:
             ln $(DESTDIR)$(bindir)/program$(EXEEXT) \
                $(DESTDIR)$(bindir)/proglink$(EXEEXT)

   Although cheaper and more portable than symbolic links, hard links
will not work everywhere (for instance, OS/2 does not have `ln').
Ideally you should fall back to `cp -p' when `ln' does not work.  An
easy way, if symbolic links are acceptable to you, is to add
`AC_PROG_LN_S' to `configure.ac' (*note Particular Program Checks:
(autoconf)Particular Programs.) and use `$(LN_S)' in `Makefile.am'.

   For instance, here is how you could install a versioned copy of a
program using `$(LN_S)':

     install-exec-hook:
             cd $(DESTDIR)$(bindir) && \
               mv -f prog$(EXEEXT) prog-$(VERSION)$(EXEEXT) && \
               $(LN_S) prog-$(VERSION)$(EXEEXT) prog$(EXEEXT)

   Note that we rename the program so that a new version will erase the
symbolic link, not the real binary.  Also we `cd' into the destination
directory in order to create relative links.

   When writing `install-exec-hook' or `install-data-hook', please bear
in mind that the exec/data distinction is based on the installation
directory, not on the primary used (*note The Two Parts of Install::).
So a `foo_SCRIPTS' will be installed by `install-data', and a
`barexec_SCRIPTS' will be installed by `install-exec'.  You should
define your hooks consequently.


File: automake.info,  Node: Third-Party Makefiles,  Prev: Extending,  Up: Not Enough

24.2 Third-Party `Makefile's
============================

In most projects all `Makefile's are generated by Automake.  In some
cases, however, projects need to embed subdirectories with handwritten
`Makefile's.  For instance, one subdirectory could be a third-party
project with its own build system, not using Automake.

   It is possible to list arbitrary directories in `SUBDIRS' or
`DIST_SUBDIRS' provided each of these directories has a `Makefile' that
recognizes all the following recursive targets.

   When a user runs one of these targets, that target is run recursively
in all subdirectories.  This is why it is important that even
third-party `Makefile's support them.

`all'
     Compile the entire package.  This is the default target in
     Automake-generated `Makefile's, but it does not need to be the
     default in third-party `Makefile's.

`distdir'
     Copy files to distribute into `$(distdir)', before a tarball is
     constructed.  Of course this target is not required if the
     `no-dist' option (*note Options::) is used.

     The variables `$(top_distdir)' and `$(distdir)' (*note The dist
     Hook::) will be passed from the outer package to the subpackage
     when the `distdir' target is invoked.  These two variables have
     been adjusted for the directory that is being recursed into, so
     they are ready to use.

`install'
`install-data'
`install-exec'
`uninstall'
     Install or uninstall files (*note Install::).

`install-dvi'
`install-html'
`install-info'
`install-ps'
`install-pdf'
     Install only some specific documentation format (*note Texinfo::).

`installdirs'
     Create install directories, but do not install any files.

`check'
`installcheck'
     Check the package (*note Tests::).

`mostlyclean'
`clean'
`distclean'
`maintainer-clean'
     Cleaning rules (*note Clean::).

`dvi'
`pdf'
`ps'
`info'
`html'
     Build the documentation in various formats (*note Texinfo::).

`tags'
`ctags'
     Build `TAGS' and `CTAGS' (*note Tags::).

   If you have ever used Gettext in a project, this is a good example of
how third-party `Makefile's can be used with Automake.  The `Makefile's
`gettextize' puts in the `po/' and `intl/' directories are handwritten
`Makefile's that implement all these targets.  That way they can be
added to `SUBDIRS' in Automake packages.

   Directories that are only listed in `DIST_SUBDIRS' but not in
`SUBDIRS' need only the `distclean', `maintainer-clean', and `distdir'
rules (*note Conditional Subdirectories::).

   Usually, many of these rules are irrelevant to the third-party
subproject, but they are required for the whole package to work.  It's
OK to have a rule that does nothing, so if you are integrating a
third-party project with no documentation or tag support, you could
simply augment its `Makefile' as follows:

     EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags
     .PHONY: $(EMPTY_AUTOMAKE_TARGETS)
     $(EMPTY_AUTOMAKE_TARGETS):

   Another aspect of integrating third-party build systems is whether
they support VPATH builds (*note VPATH Builds::).  Obviously if the
subpackage does not support VPATH builds the whole package will not
support VPATH builds.  This in turns means that `make distcheck' will
not work, because it relies on VPATH builds.  Some people can live
without this (actually, many Automake users have never heard of `make
distcheck').  Other people may prefer to revamp the existing
`Makefile's to support VPATH.  Doing so does not necessarily require
Automake, only Autoconf is needed (*note Build Directories:
(autoconf)Build Directories.).  The necessary substitutions:
`@srcdir@', `@top_srcdir@', and `@top_builddir@' are defined by
`configure' when it processes a `Makefile' (*note Preset Output
Variables: (autoconf)Preset Output Variables.), they are not computed
by the Makefile like the aforementioned `$(distdir)' and
`$(top_distdir)' variables.

   It is sometimes inconvenient to modify a third-party `Makefile' to
introduce the above required targets.  For instance, one may want to
keep the third-party sources untouched to ease upgrades to new versions.

   Here are two other ideas.  If GNU make is assumed, one possibility is
to add to that subdirectory a `GNUmakefile' that defines the required
targets and includes the third-party `Makefile'.  For this to work in
VPATH builds, `GNUmakefile' must lie in the build directory; the
easiest way to do this is to write a `GNUmakefile.in' instead, and have
it processed with `AC_CONFIG_FILES' from the outer package.  For
example if we assume `Makefile' defines all targets except the
documentation targets, and that the `check' target is actually called
`test', we could write `GNUmakefile' (or `GNUmakefile.in') like this:

     # First, include the real Makefile
     include Makefile
     # Then, define the other targets needed by Automake Makefiles.
     .PHONY: dvi pdf ps info html check
     dvi pdf ps info html:
     check: test

   A similar idea that does not use `include' is to write a proxy
`Makefile' that dispatches rules to the real `Makefile', either with
`$(MAKE) -f Makefile.real $(AM_MAKEFLAGS) target' (if it's OK to rename
the original `Makefile') or with `cd subdir && $(MAKE) $(AM_MAKEFLAGS)
target' (if it's OK to store the subdirectory project one directory
deeper).  The good news is that this proxy `Makefile' can be generated
with Automake.  All we need are `-local' targets (*note Extending::)
that perform the dispatch.  Of course the other Automake features are
available, so you could decide to let Automake perform distribution or
installation.  Here is a possible `Makefile.am':

     all-local:
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) all
     check-local:
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) test
     clean-local:
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) clean

     # Assuming the package knows how to install itself
     install-data-local:
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-data
     install-exec-local:
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-exec
     uninstall-local:
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) uninstall

     # Distribute files from here.
     EXTRA_DIST = subdir/Makefile subdir/program.c ...

   Pushing this idea to the extreme, it is also possible to ignore the
subproject build system and build everything from this proxy
`Makefile.am'.  This might sound very sensible if you need VPATH builds
but the subproject does not support them.


File: automake.info,  Node: Distributing,  Next: API Versioning,  Prev: Not Enough,  Up: Top

25 Distributing `Makefile.in's
******************************

Automake places no restrictions on the distribution of the resulting
`Makefile.in's.  We still encourage software authors to distribute
their work under terms like those of the GPL, but doing so is not
required to use Automake.

   Some of the files that can be automatically installed via the
`--add-missing' switch do fall under the GPL.  However, these also have
a special exception allowing you to distribute them with your package,
regardless of the licensing you choose.


File: automake.info,  Node: API Versioning,  Next: Upgrading,  Prev: Distributing,  Up: Top

26 Automake API Versioning
**************************

New Automake releases usually include bug fixes and new features.
Unfortunately they may also introduce new bugs and incompatibilities.
This makes four reasons why a package may require a particular Automake
version.

   Things get worse when maintaining a large tree of packages, each one
requiring a different version of Automake.  In the past, this meant that
any developer (and sometimes users) had to install several versions of
Automake in different places, and switch `$PATH' appropriately for each
package.

   Starting with version 1.6, Automake installs versioned binaries.
This means you can install several versions of Automake in the same
`$prefix', and can select an arbitrary Automake version by running
`automake-1.6' or `automake-1.7' without juggling with `$PATH'.
Furthermore, `Makefile''s generated by Automake 1.6 will use
`automake-1.6' explicitly in their rebuild rules.

   The number `1.6' in `automake-1.6' is Automake's API version, not
Automake's version.  If a bug fix release is made, for instance
Automake 1.6.1, the API version will remain 1.6.  This means that a
package that works with Automake 1.6 should also work with 1.6.1; after
all, this is what people expect from bug fix releases.

   If your package relies on a feature or a bug fix introduced in a
release, you can pass this version as an option to Automake to ensure
older releases will not be used.  For instance, use this in your
`configure.ac':

       AM_INIT_AUTOMAKE([1.6.1])    dnl Require Automake 1.6.1 or better.

or, in a particular `Makefile.am':

       AUTOMAKE_OPTIONS = 1.6.1   # Require Automake 1.6.1 or better.

Automake will print an error message if its version is older than the
requested version.

What is in the API
==================

Automake's programming interface is not easy to define.  Basically it
should include at least all *documented* variables and targets that a
`Makefile.am' author can use, any behavior associated with them (e.g.,
the places where `-hook''s are run), the command line interface of
`automake' and `aclocal', ...

What is not in the API
======================

Every undocumented variable, target, or command line option, is not part
of the API.  You should avoid using them, as they could change from one
version to the other (even in bug fix releases, if this helps to fix a
bug).

   If it turns out you need to use such an undocumented feature, contact
<automake@gnu.org> and try to get it documented and exercised by the
test-suite.


File: automake.info,  Node: Upgrading,  Next: FAQ,  Prev: API Versioning,  Up: Top

27 Upgrading a Package to a Newer Automake Version
**************************************************

Automake maintains three kind of files in a package.

   * `aclocal.m4'

   * `Makefile.in's

   * auxiliary tools like `install-sh' or `py-compile'

   `aclocal.m4' is generated by `aclocal' and contains some
Automake-supplied M4 macros.  Auxiliary tools are installed by
`automake --add-missing' when needed.  `Makefile.in's are built from
`Makefile.am' by `automake', and rely on the definitions of the M4
macros put in `aclocal.m4' as well as the behavior of the auxiliary
tools installed.

   Because all these files are closely related, it is important to
regenerate all of them when upgrading to a newer Automake release.  The
usual way to do that is

     aclocal # with any option needed (such a -I m4)
     autoconf
     automake --add-missing --force-missing

or more conveniently:

     autoreconf -vfi

   The use of `--force-missing' ensures that auxiliary tools will be
overridden by new versions (*note Invoking Automake::).

   It is important to regenerate all these files each time Automake is
upgraded, even between bug fixes releases.  For instance, it is not
unusual for a bug fix to involve changes to both the rules generated in
`Makefile.in' and the supporting M4 macros copied to `aclocal.m4'.

   Presently `automake' is able to diagnose situations where
`aclocal.m4' has been generated with another version of `aclocal'.
However it never checks whether auxiliary scripts are up-to-date.  In
other words, `automake' will tell you when `aclocal' needs to be rerun,
but it will never diagnose a missing `--force-missing'.

   Before upgrading to a new major release, it is a good idea to read
the file `NEWS'.  This file lists all changes between releases: new
features, obsolete constructs, known incompatibilities, and workarounds.


File: automake.info,  Node: FAQ,  Next: History,  Prev: Upgrading,  Up: Top

28 Frequently Asked Questions about Automake
********************************************

This chapter covers some questions that often come up on the mailing
lists.

* Menu:

* CVS::                         CVS and generated files
* maintainer-mode::             missing and AM_MAINTAINER_MODE
* Wildcards::                   Why doesn't Automake support wildcards?
* Limitations on File Names::   Limitations on source and installed file names
* distcleancheck::              Files left in build directory after distclean
* Flag Variables Ordering::     CFLAGS vs. AM_CFLAGS vs. mumble_CFLAGS
* Renamed Objects::             Why are object files sometimes renamed?
* Per-Object Flags::            How to simulate per-object flags?
* Multiple Outputs::            Writing rules for tools with many output files
* Hard-Coded Install Paths::    Installing to hard-coded locations
* Debugging Make Rules::        Strategies when things don't work as expected
* Reporting Bugs::              Feedback on bugs and feature requests


File: automake.info,  Node: CVS,  Next: maintainer-mode,  Up: FAQ

28.1 CVS and generated files
============================

Background: distributed generated Files
---------------------------------------

Packages made with Autoconf and Automake ship with some generated files
like `configure' or `Makefile.in'.  These files were generated on the
developer's host and are distributed so that end-users do not have to
install the maintainer tools required to rebuild them.  Other generated
files like Lex scanners, Yacc parsers, or Info documentation, are
usually distributed on similar grounds.

   Automake outputs rules in `Makefile's to rebuild these files.  For
instance, `make' will run `autoconf' to rebuild `configure' whenever
`configure.ac' is changed.  This makes development safer by ensuring a
`configure' is never out-of-date with respect to `configure.ac'.

   As generated files shipped in packages are up-to-date, and because
`tar' preserves times-tamps, these rebuild rules are not triggered when
a user unpacks and builds a package.

Background: CVS and Timestamps
------------------------------

Unless you use CVS keywords (in which case files must be updated at
commit time), CVS preserves timestamp during `cvs commit' and `cvs
import -d' operations.

   When you check out a file using `cvs checkout' its timestamp is set
to that of the revision that is being checked out.

   However, during `cvs update', files will have the date of the
update, not the original timestamp of this revision.  This is meant to
make sure that `make' notices sources files have been updated.

   This timestamp shift is troublesome when both sources and generated
files are kept under CVS.  Because CVS processes files in lexical
order, `configure.ac' will appear newer than `configure' after a `cvs
update' that updates both files, even if `configure' was newer than
`configure.ac' when it was checked in.  Calling `make' will then
trigger a spurious rebuild of `configure'.

Living with CVS in Autoconfiscated Projects
-------------------------------------------

There are basically two clans amongst maintainers: those who keep all
distributed files under CVS, including generated files, and those who
keep generated files _out_ of CVS.

All Files in CVS
................

   * The CVS repository contains all distributed files so you know
     exactly what is distributed, and you can checkout any prior
     version entirely.

   * Maintainers can see how generated files evolve (for instance, you
     can see what happens to your `Makefile.in's when you upgrade
     Automake and make sure they look OK).

   * Users do not need the autotools to build a checkout of the
     project, it works just like a released tarball.

   * If users use `cvs update' to update their copy, instead of `cvs
     checkout' to fetch a fresh one, timestamps will be inaccurate.
     Some rebuild rules will be triggered and attempt to run developer
     tools such as `autoconf' or `automake'.

     Actually, calls to such tools are all wrapped into a call to the
     `missing' script discussed later (*note maintainer-mode::).
     `missing' will take care of fixing the timestamps when these tools
     are not installed, so that the build can continue.

   * In distributed development, developers are likely to have different
     version of the maintainer tools installed.  In this case rebuilds
     triggered by timestamp lossage will lead to spurious changes to
     generated files.  There are several solutions to this:

        * All developers should use the same versions, so that the
          rebuilt files are identical to files in CVS.  (This starts to
          be difficult when each project you work on uses different
          versions.)

        * Or people use a script to fix the timestamp after a checkout
          (the GCC folks have such a script).

        * Or `configure.ac' uses `AM_MAINTAINER_MODE', which will
          disable all these rebuild rules by default.  This is further
          discussed in *note maintainer-mode::.

   * Although we focused on spurious rebuilds, the converse can also
     happen.  CVS's timestamp handling can also let you think an
     out-of-date file is up-to-date.

     For instance, suppose a developer has modified `Makefile.am' and
     has rebuilt `Makefile.in', and then decides to do a last-minute
     change to `Makefile.am' right before checking in both files
     (without rebuilding `Makefile.in' to account for the change).

     This last change to `Makefile.am' makes the copy of `Makefile.in'
     out-of-date.  Since CVS processes files alphabetically, when
     another developer `cvs update's his or her tree, `Makefile.in'
     will happen to be newer than `Makefile.am'.  This other developer
     will not see that `Makefile.in' is out-of-date.


Generated Files out of CVS
..........................

One way to get CVS and `make' working peacefully is to never store
generated files in CVS, i.e., do not CVS-control files that are
`Makefile' targets (also called _derived_ files).

   This way developers are not annoyed by changes to generated files.
It does not matter if they all have different versions (assuming they
are compatible, of course).  And finally, timestamps are not lost,
changes to sources files can't be missed as in the
`Makefile.am'/`Makefile.in' example discussed earlier.

   The drawback is that the CVS repository is not an exact copy of what
is distributed and that users now need to install various development
tools (maybe even specific versions) before they can build a checkout.
But, after all, CVS's job is versioning, not distribution.

   Allowing developers to use different versions of their tools can also
hide bugs during distributed development.  Indeed, developers will be
using (hence testing) their own generated files, instead of the
generated files that will be released actually.  The developer who
prepares the tarball might be using a version of the tool that produces
bogus output (for instance a non-portable C file), something other
developers could have noticed if they weren't using their own versions
of this tool.

Third-party Files
-----------------

Another class of files not discussed here (because they do not cause
timestamp issues) are files that are shipped with a package, but
maintained elsewhere.  For instance, tools like `gettextize' and
`autopoint' (from Gettext) or `libtoolize' (from Libtool), will install
or update files in your package.

   These files, whether they are kept under CVS or not, raise similar
concerns about version mismatch between developers' tools.  The Gettext
manual has a section about this, see *note CVS Issues: (gettext)CVS
Issues.


File: automake.info,  Node: maintainer-mode,  Next: Wildcards,  Prev: CVS,  Up: FAQ

28.2 `missing' and `AM_MAINTAINER_MODE'
=======================================

`missing'
---------

The `missing' script is a wrapper around several maintainer tools,
designed to warn users if a maintainer tool is required but missing.
Typical maintainer tools are `autoconf', `automake', `bison', etc.
Because file generated by these tools are shipped with the other
sources of a package, these tools shouldn't be required during a user
build and they are not checked for in `configure'.

   However, if for some reason a rebuild rule is triggered and involves
a missing tool, `missing' will notice it and warn the user.  Besides
the warning, when a tool is missing, `missing' will attempt to fix
timestamps in a way that allows the build to continue.  For instance,
`missing' will touch `configure' if `autoconf' is not installed.  When
all distributed files are kept under version control, this feature of
`missing' allows a user _with no maintainer tools_ to build a package
off its version control repository, bypassing any timestamp
inconsistency (implied by e.g. `cvs update' or `git clone').

   If the required tool is installed, `missing' will run it and won't
attempt to continue after failures.  This is correct during
development: developers love fixing failures.  However, users with
wrong versions of maintainer tools may get an error when the rebuild
rule is spuriously triggered, halting the build.  This failure to let
the build continue is one of the arguments of the `AM_MAINTAINER_MODE'
advocates.

`AM_MAINTAINER_MODE'
--------------------

`AM_MAINTAINER_MODE' allows you to choose whether the so called
"rebuild rules" should be enabled or disabled.  With
`AM_MAINTAINER_MODE([enable])', they are enabled by default, otherwise
they are disabled by default.  In the latter case, if you have
`AM_MAINTAINER_MODE' in `configure.ac', and run `./configure && make',
then `make' will *never* attempt to rebuild `configure',
`Makefile.in's, Lex or Yacc outputs, etc.  I.e., this disables build
rules for files that are usually distributed and that users should
normally not have to update.

   The user can override the default setting by passing either
`--enable-maintainer-mode' or `--disable-maintainer-mode' to
`configure'.

   People use `AM_MAINTAINER_MODE' either because they do not want their
users (or themselves) annoyed by timestamps lossage (*note CVS::), or
because they simply can't stand the rebuild rules and prefer running
maintainer tools explicitly.

   `AM_MAINTAINER_MODE' also allows you to disable some custom build
rules conditionally.  Some developers use this feature to disable rules
that need exotic tools that users may not have available.

   Several years ago Franc,ois Pinard pointed out several arguments
against this `AM_MAINTAINER_MODE' macro.  Most of them relate to
insecurity.  By removing dependencies you get non-dependable builds:
changes to sources files can have no effect on generated files and this
can be very confusing when unnoticed.  He adds that security shouldn't
be reserved to maintainers (what `--enable-maintainer-mode' suggests),
on the contrary.  If one user has to modify a `Makefile.am', then
either `Makefile.in' should be updated or a warning should be output
(this is what Automake uses `missing' for) but the last thing you want
is that nothing happens and the user doesn't notice it (this is what
happens when rebuild rules are disabled by `AM_MAINTAINER_MODE').

   Jim Meyering, the inventor of the `AM_MAINTAINER_MODE' macro was
swayed by Franc,ois's arguments, and got rid of `AM_MAINTAINER_MODE' in
all of his packages.

   Still many people continue to use `AM_MAINTAINER_MODE', because it
helps them working on projects where all files are kept under version
control, and because `missing' isn't enough if you have the wrong
version of the tools.


File: automake.info,  Node: Wildcards,  Next: Limitations on File Names,  Prev: maintainer-mode,  Up: FAQ

28.3 Why doesn't Automake support wildcards?
============================================

Developers are lazy.  They would often like to use wildcards in
`Makefile.am's, so that they would not need to remember to update
`Makefile.am's every time they add, delete, or rename a file.

   There are several objections to this:
   * When using CVS (or similar) developers need to remember they have
     to run `cvs add' or `cvs rm' anyway.  Updating `Makefile.am'
     accordingly quickly becomes a reflex.

     Conversely, if your application doesn't compile because you forgot
     to add a file in `Makefile.am', it will help you remember to `cvs
     add' it.

   * Using wildcards makes it easy to distribute files by mistake.  For
     instance, some code a developer is experimenting with (a test case,
     say) that should not be part of the distribution.

   * Using wildcards it's easy to omit some files by mistake.  For
     instance, one developer creates a new file, uses it in many places,
     but forgets to commit it.  Another developer then checks out the
     incomplete project and is able to run `make dist' successfully,
     even though a file is missing. By listing files, `make dist'
     _will_ complain.

   * Wildcards are not portable to some non-GNU `make' implementations,
     e.g., NetBSD `make' will not expand globs such as `*' in
     prerequisites of a target.

   * Finally, it's really hard to _forget_ to add a file to
     `Makefile.am': files that are not listed in `Makefile.am' are not
     compiled or installed, so you can't even test them.

   Still, these are philosophical objections, and as such you may
disagree, or find enough value in wildcards to dismiss all of them.
Before you start writing a patch against Automake to teach it about
wildcards, let's see the main technical issue: portability.

   Although `$(wildcard ...)' works with GNU `make', it is not portable
to other `make' implementations.

   The only way Automake could support `$(wildcard ...)' is by
expending `$(wildcard ...)' when `automake' is run.  The resulting
`Makefile.in's would be portable since they would list all files and
not use `$(wildcard ...)'.  However that means developers would need to
remember to run `automake' each time they add, delete, or rename files.

   Compared to editing `Makefile.am', this is a very small gain.  Sure,
it's easier and faster to type `automake; make' than to type `emacs
Makefile.am; make'.  But nobody bothered enough to write a patch to add
support for this syntax.  Some people use scripts to generate file
lists in `Makefile.am' or in separate `Makefile' fragments.

   Even if you don't care about portability, and are tempted to use
`$(wildcard ...)' anyway because you target only GNU Make, you should
know there are many places where Automake needs to know exactly which
files should be processed.  As Automake doesn't know how to expand
`$(wildcard ...)', you cannot use it in these places.  `$(wildcard
...)' is a black box comparable to `AC_SUBST'ed variables as far
Automake is concerned.

   You can get warnings about `$(wildcard ...') constructs using the
`-Wportability' flag.


File: automake.info,  Node: Limitations on File Names,  Next: distcleancheck,  Prev: Wildcards,  Up: FAQ

28.4 Limitations on File Names
==============================

Automake attempts to support all kinds of file names, even those that
contain unusual characters or are unusually long.  However, some
limitations are imposed by the underlying operating system and tools.

   Most operating systems prohibit the use of the null byte in file
names, and reserve `/' as a directory separator.  Also, they require
that file names are properly encoded for the user's locale.  Automake
is subject to these limits.

   Portable packages should limit themselves to POSIX file names.
These can contain ASCII letters and digits, `_', `.', and `-'.  File
names consist of components separated by `/'.  File name components
cannot begin with `-'.

   Portable POSIX file names cannot contain components that exceed a
14-byte limit, but nowadays it's normally safe to assume the
more-generous XOPEN limit of 255 bytes.  POSIX limits file names to 255
bytes (XOPEN allows 1023 bytes), but you may want to limit a source
tarball to file names of 99 bytes to avoid interoperability problems
with old versions of `tar'.

   If you depart from these rules (e.g., by using non-ASCII characters
in file names, or by using lengthy file names), your installers may
have problems for reasons unrelated to Automake.  However, if this does
not concern you, you should know about the limitations imposed by
Automake itself.  These limitations are undesirable, but some of them
seem to be inherent to underlying tools like Autoconf, Make, M4, and
the shell.  They fall into three categories: install directories, build
directories, and file names.

   The following characters:

     newline " # $ ' `

   should not appear in the names of install directories.  For example,
the operand of `configure''s `--prefix' option should not contain these
characters.

   Build directories suffer the same limitations as install directories,
and in addition should not contain the following characters:

     & @ \

   For example, the full name of the directory containing the source
files should not contain these characters.

   Source and installation file names like `main.c' are limited even
further: they should conform to the POSIX/XOPEN rules described above.
In addition, if you plan to port to non-POSIX environments, you should
avoid file names that differ only in case (e.g., `makefile' and
`Makefile').  Nowadays it is no longer worth worrying about the 8.3
limits of DOS file systems.


File: automake.info,  Node: distcleancheck,  Next: Flag Variables Ordering,  Prev: Limitations on File Names,  Up: FAQ

28.5 Files left in build directory after distclean
==================================================

This is a diagnostic you might encounter while running `make distcheck'.

   As explained in *note Checking the Distribution::, `make distcheck'
attempts to build and check your package for errors like this one.

   `make distcheck' will perform a `VPATH' build of your package (*note
VPATH Builds::), and then call `make distclean'.  Files left in the
build directory after `make distclean' has run are listed after this
error.

   This diagnostic really covers two kinds of errors:

   * files that are forgotten by distclean;

   * distributed files that are erroneously rebuilt.

   The former left-over files are not distributed, so the fix is to mark
them for cleaning (*note Clean::), this is obvious and doesn't deserve
more explanations.

   The latter bug is not always easy to understand and fix, so let's
proceed with an example.  Suppose our package contains a program for
which we want to build a man page using `help2man'.  GNU `help2man'
produces simple manual pages from the `--help' and `--version' output
of other commands (*note Overview: (help2man)Top.).  Because we don't
want to force our users to install `help2man', we decide to distribute
the generated man page using the following setup.

     # This Makefile.am is bogus.
     bin_PROGRAMS = foo
     foo_SOURCES = foo.c
     dist_man_MANS = foo.1

     foo.1: foo$(EXEEXT)
             help2man --output=foo.1 ./foo$(EXEEXT)

   This will effectively distribute the man page.  However, `make
distcheck' will fail with:

     ERROR: files left in build directory after distclean:
     ./foo.1

   Why was `foo.1' rebuilt?  Because although distributed, `foo.1'
depends on a non-distributed built file: `foo$(EXEEXT)'.
`foo$(EXEEXT)' is built by the user, so it will always appear to be
newer than the distributed `foo.1'.

   `make distcheck' caught an inconsistency in our package.  Our intent
was to distribute `foo.1' so users do not need to install `help2man',
however since this rule causes this file to be always rebuilt, users
_do_ need `help2man'.  Either we should ensure that `foo.1' is not
rebuilt by users, or there is no point in distributing `foo.1'.

   More generally, the rule is that distributed files should never
depend on non-distributed built files.  If you distribute something
generated, distribute its sources.

   One way to fix the above example, while still distributing `foo.1'
is to not depend on `foo$(EXEEXT)'.  For instance, assuming `foo
--version' and `foo --help' do not change unless `foo.c' or
`configure.ac' change, we could write the following `Makefile.am':

     bin_PROGRAMS = foo
     foo_SOURCES = foo.c
     dist_man_MANS = foo.1

     foo.1: foo.c $(top_srcdir)/configure.ac
             $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
             help2man --output=foo.1 ./foo$(EXEEXT)

   This way, `foo.1' will not get rebuilt every time `foo$(EXEEXT)'
changes.  The `make' call makes sure `foo$(EXEEXT)' is up-to-date
before `help2man'.  Another way to ensure this would be to use separate
directories for binaries and man pages, and set `SUBDIRS' so that
binaries are built before man pages.

   We could also decide not to distribute `foo.1'.  In this case it's
fine to have `foo.1' dependent upon `foo$(EXEEXT)', since both will
have to be rebuilt.  However it would be impossible to build the
package in a cross-compilation, because building `foo.1' involves an
_execution_ of `foo$(EXEEXT)'.

   Another context where such errors are common is when distributed
files are built by tools that are built by the package.  The pattern is
similar:

     distributed-file: built-tools distributed-sources
             build-command

should be changed to

     distributed-file: distributed-sources
             $(MAKE) $(AM_MAKEFLAGS) built-tools
             build-command

or you could choose not to distribute `distributed-file', if
cross-compilation does not matter.

   The points made through these examples are worth a summary:

   * Distributed files should never depend upon non-distributed built
     files.

   * Distributed files should be distributed with all their
     dependencies.

   * If a file is _intended_ to be rebuilt by users, then there is no
     point in distributing it.

   For desperate cases, it's always possible to disable this check by
setting `distcleancheck_listfiles' as documented in *note Checking the
Distribution::.  Make sure you do understand the reason why `make
distcheck' complains before you do this.  `distcleancheck_listfiles' is
a way to _hide_ errors, not to fix them.  You can always do better.


File: automake.info,  Node: Flag Variables Ordering,  Next: Renamed Objects,  Prev: distcleancheck,  Up: FAQ

28.6 Flag Variables Ordering
============================

     What is the difference between `AM_CFLAGS', `CFLAGS', and
     `mumble_CFLAGS'?

     Why does `automake' output `CPPFLAGS' after
     `AM_CPPFLAGS' on compile lines?  Shouldn't it be the converse?

     My `configure' adds some warning flags into `CXXFLAGS'.  In
     one `Makefile.am' I would like to append a new flag, however if I
     put the flag into `AM_CXXFLAGS' it is prepended to the other
     flags, not appended.

Compile Flag Variables
----------------------

This section attempts to answer all the above questions.  We will
mostly discuss `CPPFLAGS' in our examples, but actually the answer
holds for all the compile flags used in Automake: `CCASFLAGS',
`CFLAGS', `CPPFLAGS', `CXXFLAGS', `FCFLAGS', `FFLAGS', `GCJFLAGS',
`LDFLAGS', `LFLAGS', `LIBTOOLFLAGS', `OBJCFLAGS', `RFLAGS', `UPCFLAGS',
and `YFLAGS'.

   `CPPFLAGS', `AM_CPPFLAGS', and `mumble_CPPFLAGS' are three variables
that can be used to pass flags to the C preprocessor (actually these
variables are also used for other languages like C++ or preprocessed
Fortran).  `CPPFLAGS' is the user variable (*note User Variables::),
`AM_CPPFLAGS' is the Automake variable, and `mumble_CPPFLAGS' is the
variable specific to the `mumble' target (we call this a per-target
variable, *note Program and Library Variables::).

   Automake always uses two of these variables when compiling C sources
files.  When compiling an object file for the `mumble' target, the
first variable will be `mumble_CPPFLAGS' if it is defined, or
`AM_CPPFLAGS' otherwise.  The second variable is always `CPPFLAGS'.

   In the following example,

     bin_PROGRAMS = foo bar
     foo_SOURCES = xyz.c
     bar_SOURCES = main.c
     foo_CPPFLAGS = -DFOO
     AM_CPPFLAGS = -DBAZ

`xyz.o' will be compiled with `$(foo_CPPFLAGS) $(CPPFLAGS)', (because
`xyz.o' is part of the `foo' target), while `main.o' will be compiled
with `$(AM_CPPFLAGS) $(CPPFLAGS)' (because there is no per-target
variable for target `bar').

   The difference between `mumble_CPPFLAGS' and `AM_CPPFLAGS' being
clear enough, let's focus on `CPPFLAGS'.  `CPPFLAGS' is a user
variable, i.e., a variable that users are entitled to modify in order
to compile the package.  This variable, like many others, is documented
at the end of the output of `configure --help'.

   For instance, someone who needs to add `/home/my/usr/include' to the
C compiler's search path would configure a package with

     ./configure CPPFLAGS='-I /home/my/usr/include'

and this flag would be propagated to the compile rules of all
`Makefile's.

   It is also not uncommon to override a user variable at `make'-time.
Many installers do this with `prefix', but this can be useful with
compiler flags too.  For instance, if, while debugging a C++ project,
you need to disable optimization in one specific object file, you can
run something like

     rm file.o
     make CXXFLAGS=-O0 file.o
     make

   The reason `$(CPPFLAGS)' appears after `$(AM_CPPFLAGS)' or
`$(mumble_CPPFLAGS)' in the compile command is that users should always
have the last say.  It probably makes more sense if you think about it
while looking at the `CXXFLAGS=-O0' above, which should supersede any
other switch from `AM_CXXFLAGS' or `mumble_CXXFLAGS' (and this of
course replaces the previous value of `CXXFLAGS').

   You should never redefine a user variable such as `CPPFLAGS' in
`Makefile.am'.  Use `automake -Woverride' to diagnose such mistakes.
Even something like

     CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@

is erroneous.  Although this preserves `configure''s value of
`CPPFLAGS', the definition of `DATADIR' will disappear if a user
attempts to override `CPPFLAGS' from the `make' command line.

     AM_CPPFLAGS = -DDATADIR=\"$(datadir)\"

is all that is needed here if no per-target flags are used.

   You should not add options to these user variables within
`configure' either, for the same reason.  Occasionally you need to
modify these variables to perform a test, but you should reset their
values afterwards.  In contrast, it is OK to modify the `AM_' variables
within `configure' if you `AC_SUBST' them, but it is rather rare that
you need to do this, unless you really want to change the default
definitions of the `AM_' variables in all `Makefile's.

   What we recommend is that you define extra flags in separate
variables.  For instance, you may write an Autoconf macro that computes
a set of warning options for the C compiler, and `AC_SUBST' them in
`WARNINGCFLAGS'; you may also have an Autoconf macro that determines
which compiler and which linker flags should be used to link with
library `libfoo', and `AC_SUBST' these in `LIBFOOCFLAGS' and
`LIBFOOLDFLAGS'.  Then, a `Makefile.am' could use these variables as
follows:

     AM_CFLAGS = $(WARNINGCFLAGS)
     bin_PROGRAMS = prog1 prog2
     prog1_SOURCES = ...
     prog2_SOURCES = ...
     prog2_CFLAGS = $(LIBFOOCFLAGS) $(AM_CFLAGS)
     prog2_LDFLAGS = $(LIBFOOLDFLAGS)

   In this example both programs will be compiled with the flags
substituted into `$(WARNINGCFLAGS)', and `prog2' will additionally be
compiled with the flags required to link with `libfoo'.

   Note that listing `AM_CFLAGS' in a per-target `CFLAGS' variable is a
common idiom to ensure that `AM_CFLAGS' applies to every target in a
`Makefile.in'.

   Using variables like this gives you full control over the ordering of
the flags.  For instance, if there is a flag in $(WARNINGCFLAGS) that
you want to negate for a particular target, you can use something like
`prog1_CFLAGS = $(AM_CFLAGS) -no-flag'.  If all these flags had been
forcefully appended to `CFLAGS', there would be no way to disable one
flag.  Yet another reason to leave user variables to users.

   Finally, we have avoided naming the variable of the example
`LIBFOO_LDFLAGS' (with an underscore) because that would cause Automake
to think that this is actually a per-target variable (like
`mumble_LDFLAGS') for some non-declared `LIBFOO' target.

Other Variables
---------------

There are other variables in Automake that follow similar principles to
allow user options.  For instance, Texinfo rules (*note Texinfo::) use
`MAKEINFOFLAGS' and `AM_MAKEINFOFLAGS'.  Similarly, DejaGnu tests
(*note DejaGnu Tests::) use `RUNTESTDEFAULTFLAGS' and
`AM_RUNTESTDEFAULTFLAGS'.  The tags and ctags rules (*note Tags::) use
`ETAGSFLAGS', `AM_ETAGSFLAGS', `CTAGSFLAGS', and `AM_CTAGSFLAGS'.  Java
rules (*note Java::) use `JAVACFLAGS' and `AM_JAVACFLAGS'.  None of
these rules support per-target flags (yet).

   To some extent, even `AM_MAKEFLAGS' (*note Subdirectories::) obeys
this naming scheme.  The slight difference is that `MAKEFLAGS' is
passed to sub-`make's implicitly by `make' itself.

   However you should not think that all variables ending with `FLAGS'
follow this convention.  For instance, `DISTCHECK_CONFIGURE_FLAGS'
(*note Checking the Distribution::) and `ACLOCAL_AMFLAGS' (see *note
Rebuilding:: and *note Local Macros::), are two variables that are only
useful to the maintainer and have no user counterpart.

   `ARFLAGS' (*note A Library::) is usually defined by Automake and has
neither `AM_' nor per-target cousin.

   Finally you should not think that the existence of a per-target
variable implies the existance of an `AM_' variable or of a user
variable.  For instance, the `mumble_LDADD' per-target variable
overrides the makefile-wide `LDADD' variable (which is not a user
variable), and `mumble_LIBADD' exists only as a per-target variable.
*Note Program and Library Variables::.


File: automake.info,  Node: Renamed Objects,  Next: Per-Object Flags,  Prev: Flag Variables Ordering,  Up: FAQ

28.7 Why are object files sometimes renamed?
============================================

This happens when per-target compilation flags are used.  Object files
need to be renamed just in case they would clash with object files
compiled from the same sources, but with different flags.  Consider the
following example.

     bin_PROGRAMS = true false
     true_SOURCES = generic.c
     true_CPPFLAGS = -DEXIT_CODE=0
     false_SOURCES = generic.c
     false_CPPFLAGS = -DEXIT_CODE=1

Obviously the two programs are built from the same source, but it would
be bad if they shared the same object, because `generic.o' cannot be
built with both `-DEXIT_CODE=0' _and_ `-DEXIT_CODE=1'.  Therefore
`automake' outputs rules to build two different objects:
`true-generic.o' and `false-generic.o'.

   `automake' doesn't actually look whether source files are shared to
decide if it must rename objects.  It will just rename all objects of a
target as soon as it sees per-target compilation flags used.

   It's OK to share object files when per-target compilation flags are
not used.  For instance, `true' and `false' will both use `version.o'
in the following example.

     AM_CPPFLAGS = -DVERSION=1.0
     bin_PROGRAMS = true false
     true_SOURCES = true.c version.c
     false_SOURCES = false.c version.c

   Note that the renaming of objects is also affected by the
`_SHORTNAME' variable (*note Program and Library Variables::).


File: automake.info,  Node: Per-Object Flags,  Next: Multiple Outputs,  Prev: Renamed Objects,  Up: FAQ

28.8 Per-Object Flags Emulation
===============================

     One of my source files needs to be compiled with different flags.  How
     do I do?

   Automake supports per-program and per-library compilation flags (see
*note Program and Library Variables:: and *note Flag Variables
Ordering::).  With this you can define compilation flags that apply to
all files compiled for a target.  For instance, in

     bin_PROGRAMS = foo
     foo_SOURCES = foo.c foo.h bar.c bar.h main.c
     foo_CFLAGS = -some -flags

`foo-foo.o', `foo-bar.o', and `foo-main.o' will all be compiled with
`-some -flags'.  (If you wonder about the names of these object files,
see *note Renamed Objects::.)  Note that `foo_CFLAGS' gives the flags
to use when compiling all the C sources of the _program_ `foo', it has
nothing to do with `foo.c' or `foo-foo.o' specifically.

   What if `foo.c' needs to be compiled into `foo.o' using some
specific flags, that none of the other files requires?  Obviously
per-program flags are not directly applicable here.  Something like
per-object flags are expected, i.e., flags that would be used only when
creating `foo-foo.o'.  Automake does not support that, however this is
easy to simulate using a library that contains only that object, and
compiling this library with per-library flags.

     bin_PROGRAMS = foo
     foo_SOURCES = bar.c bar.h main.c
     foo_CFLAGS = -some -flags
     foo_LDADD = libfoo.a
     noinst_LIBRARIES = libfoo.a
     libfoo_a_SOURCES = foo.c foo.h
     libfoo_a_CFLAGS = -some -other -flags

   Here `foo-bar.o' and `foo-main.o' will all be compiled with `-some
-flags', while `libfoo_a-foo.o' will be compiled using `-some -other
-flags'.  Eventually, all three objects will be linked to form `foo'.

   This trick can also be achieved using Libtool convenience libraries,
for instance `noinst_LTLIBRARIES = libfoo.la' (*note Libtool
Convenience Libraries::).

   Another tempting idea to implement per-object flags is to override
the compile rules `automake' would output for these files.  Automake
will not define a rule for a target you have defined, so you could
think about defining the `foo-foo.o: foo.c' rule yourself.  We
recommend against this, because this is error prone.  For instance, if
you add such a rule to the first example, it will break the day you
decide to remove `foo_CFLAGS' (because `foo.c' will then be compiled as
`foo.o' instead of `foo-foo.o', *note Renamed Objects::).  Also in
order to support dependency tracking, the two `.o'/`.obj' extensions,
and all the other flags variables involved in a compilation, you will
end up modifying a copy of the rule previously output by `automake' for
this file.  If a new release of Automake generates a different rule,
your copy will need to be updated by hand.


File: automake.info,  Node: Multiple Outputs,  Next: Hard-Coded Install Paths,  Prev: Per-Object Flags,  Up: FAQ

28.9 Handling Tools that Produce Many Outputs
=============================================

This section describes a `make' idiom that can be used when a tool
produces multiple output files.  It is not specific to Automake and can
be used in ordinary `Makefile's.

   Suppose we have a program called `foo' that will read one file
called `data.foo' and produce two files named `data.c' and `data.h'.
We want to write a `Makefile' rule that captures this one-to-two
dependency.

   The naive rule is incorrect:

     # This is incorrect.
     data.c data.h: data.foo
             foo data.foo

What the above rule really says is that `data.c' and `data.h' each
depend on `data.foo', and can each be built by running `foo data.foo'.
In other words it is equivalent to:

     # We do not want this.
     data.c: data.foo
             foo data.foo
     data.h: data.foo
             foo data.foo

which means that `foo' can be run twice.  Usually it will not be run
twice, because `make' implementations are smart enough to check for the
existence of the second file after the first one has been built; they
will therefore detect that it already exists.  However there are a few
situations where it can run twice anyway:

   * The most worrying case is when running a parallel `make'.  If
     `data.c' and `data.h' are built in parallel, two `foo data.foo'
     commands will run concurrently.  This is harmful.

   * Another case is when the dependency (here `data.foo') is (or
     depends upon) a phony target.

   A solution that works with parallel `make' but not with phony
dependencies is the following:

     data.c data.h: data.foo
             foo data.foo
     data.h: data.c

The above rules are equivalent to

     data.c: data.foo
             foo data.foo
     data.h: data.foo data.c
             foo data.foo

therefore a parallel `make' will have to serialize the builds of
`data.c' and `data.h', and will detect that the second is no longer
needed once the first is over.

   Using this pattern is probably enough for most cases.  However it
does not scale easily to more output files (in this scheme all output
files must be totally ordered by the dependency relation), so we will
explore a more complicated solution.

   Another idea is to write the following:

     # There is still a problem with this one.
     data.c: data.foo
             foo data.foo
     data.h: data.c

The idea is that `foo data.foo' is run only when `data.c' needs to be
updated, but we further state that `data.h' depends upon `data.c'.
That way, if `data.h' is required and `data.foo' is out of date, the
dependency on `data.c' will trigger the build.

   This is almost perfect, but suppose we have built `data.h' and
`data.c', and then we erase `data.h'.  Then, running `make data.h' will
not rebuild `data.h'.  The above rules just state that `data.c' must be
up-to-date with respect to `data.foo', and this is already the case.

   What we need is a rule that forces a rebuild when `data.h' is
missing.  Here it is:

     data.c: data.foo
             foo data.foo
     data.h: data.c
     ## Recover from the removal of $@
             @if test -f $@; then :; else \
               rm -f data.c; \
               $(MAKE) $(AM_MAKEFLAGS) data.c; \
             fi

   The above scheme can be extended to handle more outputs and more
inputs.  One of the outputs is selected to serve as a witness to the
successful completion of the command, it depends upon all inputs, and
all other outputs depend upon it.  For instance, if `foo' should
additionally read `data.bar' and also produce `data.w' and `data.x', we
would write:

     data.c: data.foo data.bar
             foo data.foo data.bar
     data.h data.w data.x: data.c
     ## Recover from the removal of $@
             @if test -f $@; then :; else \
               rm -f data.c; \
               $(MAKE) $(AM_MAKEFLAGS) data.c; \
             fi

   However there are now three minor problems in this setup.  One is
related to the timestamp ordering of `data.h', `data.w', `data.x', and
`data.c'.  Another one is a race condition if a parallel `make'
attempts to run multiple instances of the recover block at once.
Finally, the recursive rule breaks `make -n' when run with GNU `make'
(as well as some other `make' implementations), as it may remove
`data.h' even when it should not (*note How the `MAKE' Variable Works:
(make)MAKE Variable.).

   Let us deal with the first problem.  `foo' outputs four files, but
we do not know in which order these files are created.  Suppose that
`data.h' is created before `data.c'.  Then we have a weird situation.
The next time `make' is run, `data.h' will appear older than `data.c',
the second rule will be triggered, a shell will be started to execute
the `if...fi' command, but actually it will just execute the `then'
branch, that is: nothing.  In other words, because the witness we
selected is not the first file created by `foo', `make' will start a
shell to do nothing each time it is run.

   A simple riposte is to fix the timestamps when this happens.

     data.c: data.foo data.bar
             foo data.foo data.bar
     data.h data.w data.x: data.c
             @if test -f $@; then \
               touch $@; \
             else \
     ## Recover from the removal of $@
               rm -f data.c; \
               $(MAKE) $(AM_MAKEFLAGS) data.c; \
             fi

   Another solution is to use a different and dedicated file as witness,
rather than using any of `foo''s outputs.

     data.stamp: data.foo data.bar
             @rm -f data.tmp
             @touch data.tmp
             foo data.foo data.bar
             @mv -f data.tmp $@
     data.c data.h data.w data.x: data.stamp
     ## Recover from the removal of $@
             @if test -f $@; then :; else \
               rm -f data.stamp; \
               $(MAKE) $(AM_MAKEFLAGS) data.stamp; \
             fi

   `data.tmp' is created before `foo' is run, so it has a timestamp
older than output files output by `foo'.  It is then renamed to
`data.stamp' after `foo' has run, because we do not want to update
`data.stamp' if `foo' fails.

   This solution still suffers from the second problem: the race
condition in the recover rule.  If, after a successful build, a user
erases `data.c' and `data.h', and runs `make -j', then `make' may start
both recover rules in parallel.  If the two instances of the rule
execute `$(MAKE) $(AM_MAKEFLAGS) data.stamp' concurrently the build is
likely to fail (for instance, the two rules will create `data.tmp', but
only one can rename it).

   Admittedly, such a weird situation does not arise during ordinary
builds.  It occurs only when the build tree is mutilated.  Here
`data.c' and `data.h' have been explicitly removed without also
removing `data.stamp' and the other output files.  `make clean; make'
will always recover from these situations even with parallel makes, so
you may decide that the recover rule is solely to help non-parallel
make users and leave things as-is.  Fixing this requires some locking
mechanism to ensure only one instance of the recover rule rebuilds
`data.stamp'.  One could imagine something along the following lines.

     data.c data.h data.w data.x: data.stamp
     ## Recover from the removal of $@
             @if test -f $@; then :; else \
               trap 'rm -rf data.lock data.stamp' 1 2 13 15; \
     ## mkdir is a portable test-and-set
               if mkdir data.lock 2>/dev/null; then \
     ## This code is being executed by the first process.
                 rm -f data.stamp; \
                 $(MAKE) $(AM_MAKEFLAGS) data.stamp; \
                 result=$$?; rm -rf data.lock; exit $$result; \
               else \
     ## This code is being executed by the follower processes.
     ## Wait until the first process is done.
                 while test -d data.lock; do sleep 1; done; \
     ## Succeed if and only if the first process succeeded.
                 test -f data.stamp; \
               fi; \
             fi

   Using a dedicated witness, like `data.stamp', is very handy when the
list of output files is not known beforehand.  As an illustration,
consider the following rules to compile many `*.el' files into `*.elc'
files in a single command.  It does not matter how `ELFILES' is defined
(as long as it is not empty: empty targets are not accepted by POSIX).

     ELFILES = one.el two.el three.el ...
     ELCFILES = $(ELFILES:=c)

     elc-stamp: $(ELFILES)
             @rm -f elc-temp
             @touch elc-temp
             $(elisp_comp) $(ELFILES)
             @mv -f elc-temp $@

     $(ELCFILES): elc-stamp
             @if test -f $@; then :; else \
     ## Recover from the removal of $@
               trap 'rm -rf elc-lock elc-stamp' 1 2 13 15; \
               if mkdir elc-lock 2>/dev/null; then \
     ## This code is being executed by the first process.
                 rm -f elc-stamp; \
                 $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \
                 rmdir elc-lock; \
               else \
     ## This code is being executed by the follower processes.
     ## Wait until the first process is done.
                 while test -d elc-lock; do sleep 1; done; \
     ## Succeed if and only if the first process succeeded.
                 test -f elc-stamp; exit $$?; \
               fi; \
             fi

   These solutions all still suffer from the third problem, namely that
they break the promise that `make -n' should not cause any actual
changes to the tree.  For those solutions that do not create lock files,
it is possible to split the recover rules into two separate recipe
commands, one of which does all work but the recursion, and the other
invokes the recursive `$(MAKE)'.  The solutions involving locking could
act upon the contents of the `MAKEFLAGS' variable, but parsing that
portably is not easy (*note The Make Macro MAKEFLAGS: (autoconf)The
Make Macro MAKEFLAGS.).  Here is an example:

     ELFILES = one.el two.el three.el ...
     ELCFILES = $(ELFILES:=c)

     elc-stamp: $(ELFILES)
             @rm -f elc-temp
             @touch elc-temp
             $(elisp_comp) $(ELFILES)
             @mv -f elc-temp $@

     $(ELCFILES): elc-stamp
     ## Recover from the removal of $@
             @dry=; for f in x $$MAKEFLAGS; do \
               case $$f in \
                 *=*|--*);; \
                 *n*) dry=:;; \
               esac; \
             done; \
             if test -f $@; then :; else \
               $$dry trap 'rm -rf elc-lock elc-stamp' 1 2 13 15; \
               if $$dry mkdir elc-lock 2>/dev/null; then \
     ## This code is being executed by the first process.
                 $$dry rm -f elc-stamp; \
                 $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \
                 $$dry rmdir elc-lock; \
               else \
     ## This code is being executed by the follower processes.
     ## Wait until the first process is done.
                 while test -d elc-lock && test -z "$$dry"; do \
                   sleep 1; \
                 done; \
     ## Succeed if and only if the first process succeeded.
                 $$dry test -f elc-stamp; exit $$?; \
               fi; \
             fi

   For completeness it should be noted that GNU `make' is able to
express rules with multiple output files using pattern rules (*note
Pattern Rule Examples: (make)Pattern Examples.).  We do not discuss
pattern rules here because they are not portable, but they can be
convenient in packages that assume GNU `make'.


File: automake.info,  Node: Hard-Coded Install Paths,  Next: Debugging Make Rules,  Prev: Multiple Outputs,  Up: FAQ

28.10 Installing to Hard-Coded Locations
========================================

     My package needs to install some configuration file.  I tried to use
     the following rule, but `make distcheck' fails.  Why?
          # Do not do this.
          install-data-local:
                  $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile

     My package needs to populate the installation directory of another
     package at install-time.  I can easily compute that installation
     directory in `configure', but if I install files therein,
     `make distcheck' fails.  How else should I do?

   These two setups share their symptoms: `make distcheck' fails
because they are installing files to hard-coded paths.  In the later
case the path is not really hard-coded in the package, but we can
consider it to be hard-coded in the system (or in whichever tool that
supplies the path).  As long as the path does not use any of the
standard directory variables (`$(prefix)', `$(bindir)', `$(datadir)',
etc.), the effect will be the same: user-installations are impossible.

   As a (non-root) user who wants to install a package, you usually
have no right to install anything in `/usr' or `/usr/local'.  So you do
something like `./configure --prefix ~/usr' to install a package in
your own `~/usr' tree.

   If a package attempts to install something to some hard-coded path
(e.g., `/etc/afile'), regardless of this `--prefix' setting, then the
installation will fail.  `make distcheck' performs such a `--prefix'
installation, hence it will fail too.

   Now, there are some easy solutions.

   The above `install-data-local' example for installing `/etc/afile'
would be better replaced by

     sysconf_DATA = afile

by default `sysconfdir' will be `$(prefix)/etc', because this is what
the GNU Standards require.  When such a package is installed on an FHS
compliant system, the installer will have to set `--sysconfdir=/etc'.
As the maintainer of the package you should not be concerned by such
site policies: use the appropriate standard directory variable to
install your files so that the installer can easily redefine these
variables to match their site conventions.

   Installing files that should be used by another package is slightly
more involved.  Let's take an example and assume you want to install a
shared library that is a Python extension module.  If you ask Python
where to install the library, it will answer something like this:

     % python -c 'from distutils import sysconfig;
                  print sysconfig.get_python_lib(1,0)'
     /usr/lib/python2.5/site-packages

   If you indeed use this absolute path to install your shared library,
non-root users will not be able to install the package, hence distcheck
fails.

   Let's do better.  The `sysconfig.get_python_lib()' function actually
accepts a third argument that will replace Python's installation prefix.

     % python -c 'from distutils import sysconfig;
                  print sysconfig.get_python_lib(1,0,"${exec_prefix}")'
     ${exec_prefix}/lib/python2.5/site-packages

   You can also use this new path.  If you do
   * root users can install your package with the same `--prefix' as
     Python (you get the behavior of the previous attempt)

   * non-root users can install your package too, they will have the
     extension module in a place that is not searched by Python but they
     can work around this using environment variables (and if you
     installed scripts that use this shared library, it's easy to tell
     Python were to look in the beginning of your script, so the script
     works in both cases).

   The `AM_PATH_PYTHON' macro uses similar commands to define
`$(pythondir)' and `$(pyexecdir)' (*note Python::).

   Of course not all tools are as advanced as Python regarding that
substitution of PREFIX.  So another strategy is to figure the part of
the installation directory that must be preserved.  For instance, here
is how `AM_PATH_LISPDIR' (*note Emacs Lisp::) computes `$(lispdir)':

     $EMACS -batch -q -eval '(while load-path
       (princ (concat (car load-path) "\n"))
       (setq load-path (cdr load-path)))' >conftest.out
     lispdir=`sed -n
       -e 's,/$,,'
       -e '/.*\/lib\/x*emacs\/site-lisp$/{
             s,.*/lib/\(x*emacs/site-lisp\)$,${libdir}/\1,;p;q;
           }'
       -e '/.*\/share\/x*emacs\/site-lisp$/{
             s,.*/share/\(x*emacs/site-lisp\),${datarootdir}/\1,;p;q;
           }'
       conftest.out`

   I.e., it just picks the first directory that looks like
`*/lib/*emacs/site-lisp' or `*/share/*emacs/site-lisp' in the search
path of emacs, and then substitutes `${libdir}' or `${datadir}'
appropriately.

   The emacs case looks complicated because it processes a list and
expects two possible layouts, otherwise it's easy, and the benefits for
non-root users are really worth the extra `sed' invocation.


File: automake.info,  Node: Debugging Make Rules,  Next: Reporting Bugs,  Prev: Hard-Coded Install Paths,  Up: FAQ

28.11 Debugging Make Rules
==========================

The rules and dependency trees generated by `automake' can get rather
complex, and leave the developer head-scratching when things don't work
as expected.  Besides the debug options provided by the `make' command
(*note Options Summary: (make)Options Summary.), here's a couple of
further hints for debugging makefiles generated by `automake'
effectively:

   * If less verbose output has been enabled in the package with the
     `silent-rules' option (*note Options::), you can use `make V=1' to
     see the commands being executed.

   * `make -n' can help show what would be done without actually doing
     it.  Note however, that this will _still execute_ commands prefixed
     with `+', and, when using GNU `make', commands that contain the
     strings `$(MAKE)' or `${MAKE}' (*note Instead of Execution:
     (make)Instead of Execution.).  Typically, this is helpful to show
     what recursive rules would do, but it means that, in your own
     rules, you should not mix such recursion with actions that change
     any files.(1)  Furthermore, note that GNU `make' will update
     prerequisites for the `Makefile' file itself even with `-n' (*note
     Remaking Makefiles: (make)Remaking Makefiles.).

   * `make SHELL="/bin/bash -vx"' can help debug complex rules.  *Note
     The Make Macro SHELL: (autoconf)The Make Macro SHELL, for some
     portability quirks associated with this construct.

   * `echo 'print: ; @echo "$(VAR)"' | make -f Makefile -f - print' can
     be handy to examine the expanded value of variables.  You may need
     to use a target other than `print' if that is already used or a
     file with that name exists.

   * `http://bashdb.sourceforge.net/remake/' provides a modified GNU
     `make' command called `remake' that copes with complex GNU
     `make'-specific Makefiles and allows to trace execution, examine
     variables, and call rules interactively, much like a debugger.

   ---------- Footnotes ----------

   (1) Automake's `dist' and `distcheck' rules had a bug in this regard
in that they created directories even with `-n', but this has been
fixed in Automake 1.11.


File: automake.info,  Node: Reporting Bugs,  Prev: Debugging Make Rules,  Up: FAQ

28.12 Reporting Bugs
====================

Most nontrivial software has bugs.  Automake is no exception.  Although
we cannot promise we can or will fix a bug, and we might not even agree
that it is a bug, we want to hear about problems you encounter. Often we
agree they are bugs and want to fix them.

   To make it possible for us to fix a bug, please report it. In order
to do so effectively, it helps to know when and how to do it.

   Before reporting a bug, it is a good idea to see if it is already
known.  You can look at the GNU Bug Tracker (http://debbugs.gnu.org/)
and the bug-automake mailing list archives
(http://lists.gnu.org/archive/html/bug-automake/) for previous bug
reports.  We previously used a Gnats database
(http://sourceware.org/cgi-bin/gnatsweb.pl?database=automake) for bug
tracking, so some bugs might have been reported there already.  Please
do not use it for new bug reports, however.

   If the bug is not already known, it should be reported.  It is very
important to report bugs in a way that is useful and efficient.  For
this, please familiarize yourself with How to Report Bugs Effectively
(http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) and How to Ask
Questions the Smart Way
(http://catb.org/~esr/faqs/smart-questions.html).  This helps you and
developers to save time which can then be spent on fixing more bugs and
implementing more features.

   For a bug report, a feature request or other suggestions, please send
email to <bug-automake@gnu.org>.  This will then open a new bug in the
bug tracker (http://debbugs.gnu.org/automake).  Be sure to include the
versions of Autoconf and Automake that you use.  Ideally, post a
minimal `Makefile.am' and `configure.ac' that reproduces the problem
you encounter.  If you have encountered test suite failures, please
attach the `tests/test-suite.log' file.


File: automake.info,  Node: History,  Next: Copying This Manual,  Prev: FAQ,  Up: Top

29 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


File: automake.info,  Node: Timeline,  Next: Dependency Tracking Evolution,  Up: History

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

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

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

     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 these patches, then he probably
     trustingly answered OK to most of them, and finally gave up and
     let Akim apply whatever he wanted.  There was no way to keep up
     with that patch rate.

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

     All these patches were sent to and discussed on
     <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 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::).  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.info,  Node: Dependency Tracking Evolution,  Next: Releases,  Prev: Timeline,  Up: History

29.2 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


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

29.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.info,  Node: Dependencies As Side Effects,  Next: Dependencies for the User,  Prev: First Take on Dependencies,  Up: Dependency Tracking Evolution

29.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.info,  Node: Dependencies for the User,  Next: Techniques for Dependencies,  Prev: Dependencies As Side Effects,  Up: Dependency Tracking Evolution

29.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::).  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.info,  Node: Techniques for Dependencies,  Next: Recommendations for Tool Writers,  Prev: Dependencies for the User,  Up: Dependency Tracking Evolution

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


File: automake.info,  Node: Recommendations for Tool Writers,  Next: Future Directions for Dependencies,  Prev: Techniques for Dependencies,  Up: Dependency Tracking Evolution

29.2.5 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.info,  Node: Future Directions for Dependencies,  Prev: Recommendations for Tool Writers,  Up: Dependency Tracking Evolution

29.2.6 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.info,  Node: Releases,  Prev: Dependency Tracking Evolution,  Up: History

29.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)
2009-12-07   1.10.3   7892   1089   8027   3566 (40)   1535 (34)   174   636
2009-12-07   1.11.1   8722   1092   8292   4162 (42)   1730 (37)   181   739 (20)
2011-12-21   1.11.2   8822   1112   8330   4223 (42)   1821 (38)   189   915 (22)


File: automake.info,  Node: Copying This Manual,  Next: Indices,  Prev: History,  Up: Top

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

* Menu:

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


File: automake.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, 2001, 2002, 2007, 2008 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
     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.


File: automake.info,  Node: Indices,  Prev: Copying This Manual,  Up: Top

Appendix B Indices
******************

* Menu:

* Macro Index::                 Index of Autoconf macros
* Variable Index::              Index of Makefile variables
* General Index::               General index


File: automake.info,  Node: Macro Index,  Next: Variable Index,  Up: Indices

B.1 Macro Index
===============

[index]
* Menu:

* _AM_DEPENDENCIES:                      Private Macros.      (line  12)
* AC_CANONICAL_BUILD:                    Optional.            (line  11)
* AC_CANONICAL_HOST:                     Optional.            (line  12)
* AC_CANONICAL_TARGET:                   Optional.            (line  13)
* AC_CONFIG_AUX_DIR <1>:                 Subpackages.         (line   6)
* AC_CONFIG_AUX_DIR:                     Optional.            (line  19)
* AC_CONFIG_FILES:                       Requirements.        (line  15)
* AC_CONFIG_HEADERS:                     Optional.            (line  46)
* AC_CONFIG_LIBOBJ_DIR <1>:              LIBOBJS.             (line  50)
* AC_CONFIG_LIBOBJ_DIR:                  Optional.            (line  41)
* AC_CONFIG_LINKS:                       Optional.            (line  55)
* AC_CONFIG_SUBDIRS:                     Subpackages.         (line   6)
* AC_DEFUN:                              Extending aclocal.   (line  36)
* AC_F77_LIBRARY_LDFLAGS:                Optional.            (line  98)
* AC_FC_SRCEXT:                          Optional.            (line 104)
* AC_INIT:                               Public Macros.       (line  25)
* AC_LIBOBJ <1>:                         LIBOBJS.             (line  11)
* AC_LIBOBJ <2>:                         LTLIBOBJS.           (line   6)
* AC_LIBOBJ:                             Optional.            (line  65)
* AC_LIBSOURCE <1>:                      LIBOBJS.             (line  17)
* AC_LIBSOURCE:                          Optional.            (line  66)
* AC_LIBSOURCES:                         Optional.            (line  67)
* AC_OUTPUT:                             Requirements.        (line  15)
* AC_PREREQ:                             Extending aclocal.   (line  36)
* AC_PROG_CC_C_O:                        Public Macros.       (line  87)
* AC_PROG_CXX:                           Optional.            (line  85)
* AC_PROG_F77:                           Optional.            (line  93)
* AC_PROG_FC:                            Optional.            (line 109)
* AC_PROG_LEX <1>:                       Public Macros.       (line  93)
* AC_PROG_LEX:                           Optional.            (line 124)
* AC_PROG_LIBTOOL:                       Optional.            (line 114)
* AC_PROG_OBJC:                          Optional.            (line  89)
* AC_PROG_RANLIB:                        Optional.            (line  81)
* AC_PROG_YACC:                          Optional.            (line 118)
* AC_REQUIRE_AUX_FILE:                   Optional.            (line 128)
* AC_SUBST:                              Optional.            (line 137)
* AM_C_PROTOTYPES <1>:                   ANSI.                (line  35)
* AM_C_PROTOTYPES <2>:                   Obsolete Macros.     (line  13)
* AM_C_PROTOTYPES:                       Optional.            (line 150)
* AM_COND_IF <1>:                        Usage of Conditionals.
                                                              (line  66)
* AM_COND_IF:                            Optional.            (line 158)
* AM_CONDITIONAL <1>:                    Usage of Conditionals.
                                                              (line   6)
* AM_CONDITIONAL:                        Optional.            (line 155)
* AM_CONFIG_HEADER:                      Obsolete Macros.     (line  23)
* AM_DEP_TRACK:                          Private Macros.      (line  14)
* AM_ENABLE_MULTILIB:                    Public Macros.       (line   7)
* AM_GNU_GETTEXT:                        Optional.            (line 164)
* AM_GNU_GETTEXT_INTL_SUBDIR:            Optional.            (line 170)
* AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL:  Obsolete Macros.     (line  28)
* AM_INIT_AUTOMAKE <1>:                  Public Macros.       (line  16)
* AM_INIT_AUTOMAKE:                      Requirements.        (line   6)
* AM_MAINTAINER_MODE <1>:                maintainer-mode.     (line  37)
* AM_MAINTAINER_MODE:                    Rebuilding.          (line   9)
* AM_MAINTAINER_MODE([DEFAULT-MODE]):    Optional.            (line 175)
* AM_MAKE_INCLUDE:                       Private Macros.      (line  20)
* AM_OUTPUT_DEPENDENCY_COMMANDS:         Private Macros.      (line  15)
* AM_PATH_LISPDIR:                       Public Macros.       (line  60)
* AM_PATH_PYTHON:                        Python.              (line  29)
* AM_PROG_AR:                            Public Macros.       (line  75)
* AM_PROG_AS:                            Public Macros.       (line  82)
* AM_PROG_CC_C_O:                        Public Macros.       (line  87)
* AM_PROG_GCJ:                           Public Macros.       (line  98)
* AM_PROG_INSTALL_STRIP:                 Private Macros.      (line  25)
* AM_PROG_LEX:                           Public Macros.       (line  93)
* AM_PROG_MKDIR_P:                       Obsolete Macros.     (line  34)
* AM_PROG_UPC:                           Public Macros.       (line 103)
* AM_PROG_VALAC:                         Vala Support.        (line  21)
* AM_SANITY_CHECK:                       Private Macros.      (line  30)
* AM_SET_DEPDIR:                         Private Macros.      (line  13)
* AM_SILENT_RULES:                       Public Macros.       (line 109)
* AM_SUBST_NOTMAKE(VAR):                 Optional.            (line 183)
* AM_SYS_POSIX_TERMIOS:                  Obsolete Macros.     (line  56)
* AM_WITH_DMALLOC:                       Public Macros.       (line 113)
* AM_WITH_REGEX:                         Public Macros.       (line 118)
* m4_include <1>:                        Basics of Distribution.
                                                              (line  14)
* m4_include:                            Optional.            (line 193)


File: automake.info,  Node: Variable Index,  Next: General Index,  Prev: Macro Index,  Up: Indices

B.2 Variable Index
==================

[index]
* Menu:

* _DATA:                                 Data.                (line   6)
* _HEADERS:                              Headers.             (line   6)
* _LIBRARIES:                            A Library.           (line   6)
* _LISP:                                 Emacs Lisp.          (line   6)
* _LOG_COMPILE:                          Simple Tests using parallel-tests.
                                                              (line  39)
* _LOG_COMPILER:                         Simple Tests using parallel-tests.
                                                              (line  39)
* _LOG_FLAGS:                            Simple Tests using parallel-tests.
                                                              (line  39)
* _LTLIBRARIES:                          Libtool Libraries.   (line   6)
* _MANS:                                 Man Pages.           (line   6)
* _PROGRAMS <1>:                         Program Sources.     (line   6)
* _PROGRAMS:                             Uniform.             (line  11)
* _PYTHON:                               Python.              (line   6)
* _SCRIPTS:                              Scripts.             (line   6)
* _SOURCES <1>:                          Default _SOURCES.    (line   6)
* _SOURCES:                              Program Sources.     (line  32)
* _TEXINFOS:                             Texinfo.             (line   6)
* ACLOCAL_AMFLAGS <1>:                   Rebuilding.          (line  12)
* ACLOCAL_AMFLAGS:                       Local Macros.        (line  19)
* ALLOCA <1>:                            LIBOBJS.             (line   6)
* ALLOCA:                                LTLIBOBJS.           (line   6)
* AM_CCASFLAGS:                          Assembly Support.    (line  10)
* AM_CFLAGS:                             Program Variables.   (line  51)
* AM_COLOR_TESTS:                        Simple Tests.        (line  25)
* AM_CPPFLAGS <1>:                       Assembly Support.    (line  10)
* AM_CPPFLAGS:                           Program Variables.   (line  16)
* AM_CXXFLAGS:                           C++ Support.         (line  22)
* AM_DEFAULT_SOURCE_EXT:                 Default _SOURCES.    (line   6)
* AM_DEFAULT_VERBOSITY:                  Automake silent-rules Option.
                                                              (line 136)
* AM_DISTCHECK_CONFIGURE_FLAGS:          Checking the Distribution.
                                                              (line  12)
* AM_ETAGSFLAGS:                         Tags.                (line  25)
* AM_EXT_LOG_FLAGS:                      Simple Tests using parallel-tests.
                                                              (line  39)
* AM_FCFLAGS:                            Fortran 9x Support.  (line  22)
* AM_FFLAGS:                             Fortran 77 Support.  (line  22)
* AM_GCJFLAGS:                           Java Support with gcj.
                                                              (line  26)
* AM_INSTALLCHECK_STD_OPTIONS_EXEMPT:    Options.             (line 153)
* AM_JAVACFLAGS:                         Java.                (line  42)
* AM_LDFLAGS <1>:                        Program Variables.   (line  61)
* AM_LDFLAGS:                            Linking.             (line  10)
* AM_LFLAGS:                             Yacc and Lex.        (line  56)
* AM_LIBTOOLFLAGS:                       Libtool Flags.       (line   6)
* AM_LOG_FLAGS:                          Simple Tests using parallel-tests.
                                                              (line  39)
* AM_MAKEFLAGS:                          Subdirectories.      (line  29)
* AM_MAKEINFOFLAGS:                      Texinfo.             (line 109)
* AM_MAKEINFOHTMLFLAGS:                  Texinfo.             (line 110)
* AM_OBJCFLAGS:                          Objective C Support. (line  22)
* AM_RFLAGS:                             Fortran 77 Support.  (line  28)
* AM_RUNTESTFLAGS:                       DejaGnu Tests.       (line  24)
* AM_UPCFLAGS:                           Unified Parallel C Support.
                                                              (line  21)
* AM_UPDATE_INFO_DIR:                    Texinfo.             (line  86)
* AM_V_at:                               Automake silent-rules Option.
                                                              (line 136)
* AM_V_GEN:                              Automake silent-rules Option.
                                                              (line 136)
* AM_VALAFLAGS:                          Vala Support.        (line  35)
* AM_YFLAGS:                             Yacc and Lex.        (line  33)
* ANSI2KNR:                              Obsolete Macros.     (line  13)
* AR:                                    Public Macros.       (line  75)
* AUTOCONF:                              Invoking Automake.   (line  28)
* AUTOM4TE:                              Invoking aclocal.    (line  45)
* AUTOMAKE_JOBS:                         Invoking Automake.   (line 185)
* AUTOMAKE_OPTIONS <1>:                  Options.             (line  17)
* AUTOMAKE_OPTIONS <2>:                  Dependencies.        (line  34)
* AUTOMAKE_OPTIONS <3>:                  ANSI.                (line  22)
* AUTOMAKE_OPTIONS:                      Public Macros.       (line  19)
* bin_PROGRAMS:                          Program Sources.     (line   6)
* bin_SCRIPTS:                           Scripts.             (line  18)
* build_triplet:                         Optional.            (line  14)
* BUILT_SOURCES:                         Sources.             (line  27)
* BZIP2:                                 The Types of Distributions.
                                                              (line   9)
* CC:                                    Program Variables.   (line  12)
* CCAS <1>:                              Assembly Support.    (line  10)
* CCAS:                                  Public Macros.       (line  82)
* CCASFLAGS <1>:                         Assembly Support.    (line  10)
* CCASFLAGS:                             Public Macros.       (line  82)
* CFLAGS:                                Program Variables.   (line  12)
* check_:                                Uniform.             (line  96)
* check_LTLIBRARIES:                     Libtool Convenience Libraries.
                                                              (line   6)
* check_PROGRAMS <1>:                    Default _SOURCES.    (line  28)
* check_PROGRAMS:                        Program Sources.     (line   6)
* check_SCRIPTS:                         Scripts.             (line  18)
* CLASSPATH_ENV:                         Java.                (line  51)
* CLEANFILES:                            Clean.               (line  13)
* COMPILE:                               Program Variables.   (line  57)
* CONFIG_STATUS_DEPENDENCIES:            Rebuilding.          (line  19)
* CONFIGURE_DEPENDENCIES:                Rebuilding.          (line  19)
* CPPFLAGS <1>:                          Assembly Support.    (line  10)
* CPPFLAGS:                              Program Variables.   (line  12)
* CXX:                                   C++ Support.         (line  16)
* CXXCOMPILE:                            C++ Support.         (line  25)
* CXXFLAGS:                              C++ Support.         (line  19)
* CXXLINK <1>:                           How the Linker is Chosen.
                                                              (line  12)
* CXXLINK:                               C++ Support.         (line  29)
* DATA <1>:                              Data.                (line   7)
* DATA:                                  Uniform.             (line 102)
* data_DATA:                             Data.                (line   9)
* DEFS:                                  Program Variables.   (line  12)
* DEJATOOL:                              DejaGnu Tests.       (line  19)
* DESTDIR <1>:                           Staged Installs.     (line   6)
* DESTDIR:                               DESTDIR.             (line   6)
* DISABLE_HARD_ERRORS:                   Simple Tests using parallel-tests.
                                                              (line  77)
* dist_ <1>:                             Fine-grained Distribution Control.
                                                              (line   6)
* dist_:                                 Alternative.         (line  29)
* dist_lisp_LISP:                        Emacs Lisp.          (line  11)
* dist_noinst_LISP:                      Emacs Lisp.          (line  11)
* DIST_SUBDIRS <1>:                      Basics of Distribution.
                                                              (line  42)
* DIST_SUBDIRS:                          Subdirectories with AM_CONDITIONAL.
                                                              (line  25)
* DISTCHECK_CONFIGURE_FLAGS:             Checking the Distribution.
                                                              (line  12)
* distcleancheck_listfiles <1>:          distcleancheck.      (line 115)
* distcleancheck_listfiles:              Checking the Distribution.
                                                              (line   6)
* DISTCLEANFILES <1>:                    Checking the Distribution.
                                                              (line  45)
* DISTCLEANFILES:                        Clean.               (line  13)
* distdir <1>:                           Third-Party Makefiles.
                                                              (line  25)
* distdir:                               The dist Hook.       (line  24)
* distuninstallcheck_listfiles:          Checking the Distribution.
                                                              (line   6)
* DVIPS:                                 Texinfo.             (line 135)
* EMACS:                                 Public Macros.       (line  60)
* ETAGS_ARGS:                            Tags.                (line  25)
* ETAGSFLAGS:                            Tags.                (line  25)
* EXPECT:                                DejaGnu Tests.       (line  19)
* EXT_LOG_COMPILE:                       Simple Tests using parallel-tests.
                                                              (line  39)
* EXT_LOG_COMPILER:                      Simple Tests using parallel-tests.
                                                              (line  39)
* EXT_LOG_FLAGS:                         Simple Tests using parallel-tests.
                                                              (line  39)
* EXTRA_DIST:                            Basics of Distribution.
                                                              (line  31)
* EXTRA_maude_SOURCES:                   Program and Library Variables.
                                                              (line  53)
* EXTRA_PROGRAMS:                        Conditional Programs.
                                                              (line  15)
* F77:                                   Fortran 77 Support.  (line  16)
* F77COMPILE:                            Fortran 77 Support.  (line  31)
* F77LINK:                               How the Linker is Chosen.
                                                              (line  14)
* FC:                                    Fortran 9x Support.  (line  16)
* FCCOMPILE:                             Fortran 9x Support.  (line  25)
* FCFLAGS:                               Fortran 9x Support.  (line  19)
* FCLINK <1>:                            Fortran 9x Support.  (line  29)
* FCLINK:                                How the Linker is Chosen.
                                                              (line  16)
* FFLAGS:                                Fortran 77 Support.  (line  19)
* FLIBS:                                 Mixing Fortran 77 With C and C++.
                                                              (line  21)
* FLINK:                                 Fortran 77 Support.  (line  35)
* GCJ:                                   Public Macros.       (line  98)
* GCJFLAGS <1>:                          Java Support with gcj.
                                                              (line  16)
* GCJFLAGS:                              Public Macros.       (line  98)
* GCJLINK:                               How the Linker is Chosen.
                                                              (line  10)
* GTAGS_ARGS:                            Tags.                (line  49)
* GZIP_ENV:                              Basics of Distribution.
                                                              (line  10)
* HEADERS:                               Uniform.             (line 102)
* host_triplet:                          Optional.            (line  14)
* include_HEADERS:                       Headers.             (line   6)
* INCLUDES:                              Program Variables.   (line  45)
* info_TEXINFOS:                         Texinfo.             (line   6)
* JAVA:                                  Uniform.             (line 102)
* JAVAC:                                 Java.                (line  35)
* JAVACFLAGS:                            Java.                (line  38)
* JAVAROOT:                              Java.                (line  47)
* LDADD:                                 Linking.             (line  10)
* LDFLAGS:                               Program Variables.   (line  12)
* LFLAGS:                                Yacc and Lex.        (line  56)
* lib_LIBRARIES:                         A Library.           (line   6)
* lib_LTLIBRARIES:                       Libtool Libraries.   (line   6)
* libexec_PROGRAMS:                      Program Sources.     (line   6)
* libexec_SCRIPTS:                       Scripts.             (line  18)
* LIBOBJS <1>:                           LIBOBJS.             (line   6)
* LIBOBJS <2>:                           LTLIBOBJS.           (line   6)
* LIBOBJS:                               Optional.            (line  68)
* LIBRARIES:                             Uniform.             (line 102)
* LIBS:                                  Program Variables.   (line  12)
* LIBTOOLFLAGS:                          Libtool Flags.       (line   6)
* LINK <1>:                              How the Linker is Chosen.
                                                              (line  22)
* LINK:                                  Program Variables.   (line  66)
* LISP:                                  Uniform.             (line 102)
* lisp_LISP:                             Emacs Lisp.          (line   6)
* lispdir:                               Public Macros.       (line  60)
* localstate_DATA:                       Data.                (line   9)
* LOG_COMPILE:                           Simple Tests using parallel-tests.
                                                              (line  39)
* LOG_COMPILER:                          Simple Tests using parallel-tests.
                                                              (line  39)
* LOG_FLAGS:                             Simple Tests using parallel-tests.
                                                              (line  39)
* LTALLOCA <1>:                          LIBOBJS.             (line   6)
* LTALLOCA:                              LTLIBOBJS.           (line   6)
* LTLIBOBJS <1>:                         LIBOBJS.             (line   6)
* LTLIBOBJS:                             LTLIBOBJS.           (line   6)
* LTLIBRARIES:                           Uniform.             (line 102)
* MAINTAINERCLEANFILES:                  Clean.               (line  13)
* MAKE:                                  Subdirectories.      (line  29)
* MAKEINFO:                              Texinfo.             (line  93)
* MAKEINFOFLAGS:                         Texinfo.             (line 103)
* MAKEINFOHTML:                          Texinfo.             (line  99)
* man_MANS:                              Man Pages.           (line   6)
* MANS:                                  Uniform.             (line 102)
* maude_AR:                              Program and Library Variables.
                                                              (line  68)
* maude_CCASFLAGS:                       Program and Library Variables.
                                                              (line 166)
* maude_CFLAGS:                          Program and Library Variables.
                                                              (line 167)
* maude_CPPFLAGS:                        Program and Library Variables.
                                                              (line 168)
* maude_CXXFLAGS:                        Program and Library Variables.
                                                              (line 169)
* maude_DEPENDENCIES <1>:                Program and Library Variables.
                                                              (line 118)
* maude_DEPENDENCIES:                    Linking.             (line  41)
* maude_FFLAGS:                          Program and Library Variables.
                                                              (line 170)
* maude_GCJFLAGS:                        Program and Library Variables.
                                                              (line 171)
* maude_LDADD <1>:                       Program and Library Variables.
                                                              (line  86)
* maude_LDADD:                           Linking.             (line  17)
* maude_LDFLAGS <1>:                     Program and Library Variables.
                                                              (line 106)
* maude_LDFLAGS:                         Linking.             (line  37)
* maude_LFLAGS:                          Program and Library Variables.
                                                              (line 172)
* maude_LIBADD <1>:                      Program and Library Variables.
                                                              (line  78)
* maude_LIBADD:                          A Library.           (line  26)
* maude_LIBTOOLFLAGS <1>:                Program and Library Variables.
                                                              (line 111)
* maude_LIBTOOLFLAGS:                    Libtool Flags.       (line   6)
* maude_LINK:                            Program and Library Variables.
                                                              (line 149)
* maude_OBJCFLAGS:                       Program and Library Variables.
                                                              (line 173)
* maude_RFLAGS:                          Program and Library Variables.
                                                              (line 174)
* maude_SHORTNAME:                       Program and Library Variables.
                                                              (line 207)
* maude_SOURCES:                         Program and Library Variables.
                                                              (line  18)
* maude_UPCFLAGS:                        Program and Library Variables.
                                                              (line 175)
* maude_YFLAGS:                          Program and Library Variables.
                                                              (line 176)
* mkdir_p:                               Obsolete Macros.     (line  34)
* MKDIR_P:                               Obsolete Macros.     (line  34)
* MOSTLYCLEANFILES:                      Clean.               (line  13)
* nobase_:                               Alternative.         (line  23)
* nodist_ <1>:                           Fine-grained Distribution Control.
                                                              (line   6)
* nodist_:                               Alternative.         (line  29)
* noinst_:                               Uniform.             (line  91)
* noinst_HEADERS:                        Headers.             (line   6)
* noinst_LIBRARIES:                      A Library.           (line   6)
* noinst_LISP:                           Emacs Lisp.          (line   6)
* noinst_LTLIBRARIES:                    Libtool Convenience Libraries.
                                                              (line   6)
* noinst_PROGRAMS:                       Program Sources.     (line   6)
* noinst_SCRIPTS:                        Scripts.             (line  18)
* notrans_:                              Man Pages.           (line  54)
* OBJC:                                  Objective C Support. (line  16)
* OBJCCOMPILE:                           Objective C Support. (line  25)
* OBJCFLAGS:                             Objective C Support. (line  19)
* OBJCLINK <1>:                          How the Linker is Chosen.
                                                              (line  18)
* OBJCLINK:                              Objective C Support. (line  29)
* oldinclude_HEADERS:                    Headers.             (line   6)
* PACKAGE:                               Basics of Distribution.
                                                              (line   6)
* pkgdata_DATA:                          Data.                (line   9)
* pkgdata_SCRIPTS:                       Scripts.             (line  18)
* pkgdatadir:                            Uniform.             (line  19)
* pkginclude_HEADERS:                    Headers.             (line   6)
* pkgincludedir:                         Uniform.             (line  19)
* pkglib_LIBRARIES:                      A Library.           (line   6)
* pkglib_LTLIBRARIES:                    Libtool Libraries.   (line   6)
* pkglibdir:                             Uniform.             (line  19)
* pkglibexec_PROGRAMS:                   Program Sources.     (line   6)
* pkglibexecdir:                         Uniform.             (line  19)
* pkgpyexecdir:                          Python.              (line 105)
* pkgpythondir:                          Python.              (line  91)
* PROGRAMS:                              Uniform.             (line  17)
* pyexecdir:                             Python.              (line  96)
* PYTHON <1>:                            Python.              (line  56)
* PYTHON:                                Uniform.             (line 102)
* PYTHON_EXEC_PREFIX:                    Python.              (line  77)
* PYTHON_PLATFORM:                       Python.              (line  82)
* PYTHON_PREFIX:                         Python.              (line  72)
* PYTHON_VERSION:                        Python.              (line  68)
* pythondir:                             Python.              (line  87)
* RECHECK_LOGS:                          Simple Tests using parallel-tests.
                                                              (line 119)
* RFLAGS:                                Fortran 77 Support.  (line  25)
* RST2HTML:                              Simple Tests using parallel-tests.
                                                              (line  71)
* RUNTEST:                               DejaGnu Tests.       (line  19)
* RUNTESTDEFAULTFLAGS:                   DejaGnu Tests.       (line  14)
* RUNTESTFLAGS:                          DejaGnu Tests.       (line  24)
* sbin_PROGRAMS:                         Program Sources.     (line   6)
* sbin_SCRIPTS:                          Scripts.             (line  18)
* SCRIPTS <1>:                           Scripts.             (line   9)
* SCRIPTS:                               Uniform.             (line 102)
* sharedstate_DATA:                      Data.                (line   9)
* SOURCES <1>:                           Default _SOURCES.    (line   6)
* SOURCES:                               Program Sources.     (line  33)
* SUBDIRS <1>:                           Basics of Distribution.
                                                              (line  42)
* SUBDIRS:                               Subdirectories.      (line   8)
* SUFFIXES:                              Suffixes.            (line   6)
* sysconf_DATA:                          Data.                (line   9)
* TAGS_DEPENDENCIES:                     Tags.                (line  35)
* target_triplet:                        Optional.            (line  14)
* TEST_EXTENSIONS:                       Simple Tests using parallel-tests.
                                                              (line  27)
* TEST_LOGS:                             Simple Tests using parallel-tests.
                                                              (line  27)
* TEST_SUITE_HTML:                       Simple Tests using parallel-tests.
                                                              (line  71)
* TEST_SUITE_LOG:                        Simple Tests using parallel-tests.
                                                              (line  21)
* TESTS <1>:                             Simple Tests using parallel-tests.
                                                              (line  21)
* TESTS:                                 Simple Tests.        (line  38)
* TESTS_ENVIRONMENT:                     Simple Tests.        (line  38)
* TEXI2DVI:                              Texinfo.             (line 126)
* TEXI2PDF:                              Texinfo.             (line 131)
* TEXINFO_TEX:                           Texinfo.             (line 139)
* TEXINFOS <1>:                          Texinfo.             (line  59)
* TEXINFOS:                              Uniform.             (line 102)
* top_distdir <1>:                       Third-Party Makefiles.
                                                              (line  25)
* top_distdir:                           The dist Hook.       (line  24)
* U:                                     Obsolete Macros.     (line  13)
* UPC <1>:                               Unified Parallel C Support.
                                                              (line  15)
* UPC:                                   Public Macros.       (line 103)
* UPCCOMPILE:                            Unified Parallel C Support.
                                                              (line  24)
* UPCFLAGS:                              Unified Parallel C Support.
                                                              (line  18)
* UPCLINK <1>:                           How the Linker is Chosen.
                                                              (line  20)
* UPCLINK:                               Unified Parallel C Support.
                                                              (line  28)
* V:                                     Automake silent-rules Option.
                                                              (line 104)
* VALAC:                                 Vala Support.        (line  29)
* VALAFLAGS:                             Vala Support.        (line  32)
* VERBOSE:                               Simple Tests using parallel-tests.
                                                              (line  62)
* VERSION:                               Basics of Distribution.
                                                              (line   6)
* WARNINGS <1>:                          aclocal Options.     (line  99)
* WARNINGS:                              Invoking Automake.   (line 177)
* WITH_DMALLOC:                          Public Macros.       (line 113)
* WITH_REGEX:                            Public Macros.       (line 118)
* XFAIL_TESTS:                           Simple Tests.        (line  52)
* XZ_OPT:                                The Types of Distributions.
                                                              (line  28)
* YACC:                                  Optional.            (line 119)
* YFLAGS:                                Yacc and Lex.        (line  33)