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

This manual is for GNU Automake (version 1.15, 31 December 2014), a
program that creates GNU standards-compliant Makefiles from template
files.

   Copyright © 1995-2014 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-invocation: (automake)aclocal Invocation.   Generating aclocal.m4.
* automake-invocation: (automake)automake Invocation. Generating Makefile.in.
END-INFO-DIR-ENTRY


File: automake.info,  Node: Staged Installs,  Next: Install Rules for the User,  Prev: Extending Installation,  Up: Install

12.4 Staged Installs
====================

Automake generates support for the ‘DESTDIR’ variable in all install
rules.  ‘DESTDIR’ is used during the ‘make install’ step to relocate
install objects into a staging area.  Each object and path is prefixed
with the value of ‘DESTDIR’ before being copied into the install area.
Here is an example of typical DESTDIR usage:

     mkdir /tmp/staging &&
     make DESTDIR=/tmp/staging install

   The ‘mkdir’ command avoids a security problem if the attacker creates
a symbolic link from ‘/tmp/staging’ to a victim area; then ‘make’ places
install objects in a directory tree built under ‘/tmp/staging’.  If
‘/gnu/bin/foo’ and ‘/gnu/share/aclocal/foo.m4’ are to be installed, the
above command would install ‘/tmp/staging/gnu/bin/foo’ and
‘/tmp/staging/gnu/share/aclocal/foo.m4’.

   This feature is commonly used to build install images and packages
(*note DESTDIR::).

   Support for ‘DESTDIR’ is implemented by coding it directly into the
install rules.  If your ‘Makefile.am’ uses a local install rule (e.g.,
‘install-exec-local’) or an install hook, then you must write that code
to respect ‘DESTDIR’.

   *Note (standards)Makefile Conventions::, for another usage example.


File: automake.info,  Node: Install Rules for the User,  Prev: Staged Installs,  Up: Install

12.5 Install Rules for the User
===============================

Automake also generates rules for targets ‘uninstall’, ‘installdirs’,
and ‘install-strip’.

   Automake supports ‘uninstall-local’ and ‘uninstall-hook’.  There is
no notion of separate uninstalls for “exec” and “data”, as these
features would not provide additional functionality.

   Note that ‘uninstall’ is not meant as a replacement for a real
packaging tool.


File: automake.info,  Node: Clean,  Next: Dist,  Prev: Install,  Up: Top

13 What Gets Cleaned
********************

The GNU Makefile Standards specify a number of different clean rules.
*Note Standard Targets for Users: (standards)Standard Targets.

   Generally the files that can be cleaned are determined automatically
by Automake.  Of course, Automake also recognizes some variables that
can be defined to specify additional files to clean.  These variables
are ‘MOSTLYCLEANFILES’, ‘CLEANFILES’, ‘DISTCLEANFILES’, and
‘MAINTAINERCLEANFILES’.

   When cleaning involves more than deleting some hard-coded list of
files, it is also possible to supplement the cleaning rules with your
own commands.  Simply define a rule for any of the ‘mostlyclean-local’,
‘clean-local’, ‘distclean-local’, or ‘maintainer-clean-local’ targets
(*note Extending::).  A common case is deleting a directory, for
instance, a directory created by the test suite:

     clean-local:
             -rm -rf testSubDir

   Since ‘make’ allows only one set of rules for a given target, a more
extensible way of writing this is to use a separate target listed as a
dependency:

     clean-local: clean-local-check
     .PHONY: clean-local-check
     clean-local-check:
             -rm -rf testSubDir

   As the GNU Standards aren’t always explicit as to which files should
be removed by which rule, we’ve adopted a heuristic that we believe was
first formulated by François Pinard:

   • If ‘make’ built it, and it is commonly something that one would
     want to rebuild (for instance, a ‘.o’ file), then ‘mostlyclean’
     should delete it.

   • Otherwise, if ‘make’ built it, then ‘clean’ should delete it.

   • If ‘configure’ built it, then ‘distclean’ should delete it.

   • If the maintainer built it (for instance, a ‘.info’ file), then
     ‘maintainer-clean’ should delete it.  However ‘maintainer-clean’
     should not delete anything that needs to exist in order to run
     ‘./configure && make’.

   We recommend that you follow this same set of heuristics in your
‘Makefile.am’.

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

14 What Goes in a Distribution
******************************

* Menu:

* Basics of Distribution::      Files distributed by default
* Fine-grained Distribution Control::  ‘dist_’ and ‘nodist_’ prefixes
* The dist Hook::               A target for last-minute distribution changes
* Checking the Distribution::   ‘make distcheck’ explained
* The Types of Distributions::  A variety of formats and compression methods


File: automake.info,  Node: Basics of Distribution,  Next: Fine-grained Distribution Control,  Up: Dist

14.1 Basics of Distribution
===========================

The ‘dist’ rule in the generated ‘Makefile.in’ can be used to generate a
gzipped ‘tar’ file and other flavors of archive for distribution.  The
file is named based on the ‘PACKAGE’ and ‘VERSION’ variables
automatically defined by either the ‘AC_INIT’ invocation or by a
_deprecated_ two-arguments invocation of the ‘AM_INIT_AUTOMAKE’ macro
(see *note Public Macros:: for how these variables get their values,
from either defaults or explicit values – it’s slightly trickier than
one would expect).  More precisely the gzipped ‘tar’ file is named
‘${PACKAGE}-${VERSION}.tar.gz’.  You can use the ‘make’ variable
‘GZIP_ENV’ to control how gzip is run.  The default setting is ‘--best’.

   For the most part, the files to distribute are automatically found by
Automake: all source files are automatically included in a distribution,
as are all ‘Makefile.am’ and ‘Makefile.in’ files.  Automake also has a
built-in list of commonly used files that are automatically included if
they are found in the current directory (either physically, or as the
target of a ‘Makefile.am’ rule); this list is printed by ‘automake
--help’.  Note that some files in this list are actually distributed
only if other certain conditions hold (for example, the ‘config.h.top’
and ‘config.h.bot’ files are automatically distributed only if, e.g.,
‘AC_CONFIG_HEADERS([config.h])’ is used in ‘configure.ac’).  Also, files
that are read by ‘configure’ (i.e. the source files corresponding to the
files specified in various Autoconf macros such as ‘AC_CONFIG_FILES’ and
siblings) are automatically distributed.  Files included in a
‘Makefile.am’ (using ‘include’) or in ‘configure.ac’ (using
‘m4_include’), and helper scripts installed with ‘automake
--add-missing’ are also distributed.

   Still, sometimes there are files that must be distributed, but which
are not covered in the automatic rules.  These files should be listed in
the ‘EXTRA_DIST’ variable.  You can mention files from subdirectories in
‘EXTRA_DIST’.

   You can also mention a directory in ‘EXTRA_DIST’; in this case the
entire directory will be recursively copied into the distribution.
Please note that this will also copy _everything_ in the directory,
including, e.g., Subversion’s ‘.svn’ private directories or CVS/RCS
version control files; thus we recommend against using this feature
as-is.  However, you can use the ‘dist-hook’ feature to ameliorate the
problem; *note The dist Hook::.

   If you define ‘SUBDIRS’, Automake will recursively include the
subdirectories in the distribution.  If ‘SUBDIRS’ is defined
conditionally (*note Conditionals::), Automake will normally include all
directories that could possibly appear in ‘SUBDIRS’ in the distribution.
If you need to specify the set of directories conditionally, you can set
the variable ‘DIST_SUBDIRS’ to the exact list of subdirectories to
include in the distribution (*note Conditional Subdirectories::).


File: automake.info,  Node: Fine-grained Distribution Control,  Next: The dist Hook,  Prev: Basics of Distribution,  Up: Dist

14.2 Fine-grained Distribution Control
======================================

Sometimes you need tighter control over what does _not_ go into the
distribution; for instance, you might have source files that are
generated and that you do not want to distribute.  In this case Automake
gives fine-grained control using the ‘dist’ and ‘nodist’ prefixes.  Any
primary or ‘_SOURCES’ variable can be prefixed with ‘dist_’ to add the
listed files to the distribution.  Similarly, ‘nodist_’ can be used to
omit the files from the distribution.

   As an example, here is how you would cause some data to be
distributed while leaving some source code out of the distribution:

     dist_data_DATA = distribute-this
     bin_PROGRAMS = foo
     nodist_foo_SOURCES = do-not-distribute.c


File: automake.info,  Node: The dist Hook,  Next: Checking the Distribution,  Prev: Fine-grained Distribution Control,  Up: Dist

14.3 The dist Hook
==================

Occasionally it is useful to be able to change the distribution before
it is packaged up.  If the ‘dist-hook’ rule exists, it is run after the
distribution directory is filled, but before the actual distribution
archives are created.  One way to use this is for removing unnecessary
files that get recursively included by specifying a directory in
‘EXTRA_DIST’:

     EXTRA_DIST = doc
     dist-hook:
             rm -rf `find $(distdir)/doc -type d -name .svn`

Note that the ‘dist-hook’ recipe shouldn’t assume that the regular files
in the distribution directory are writable; this might not be the case
if one is packaging from a read-only source tree, or when a ‘make
distcheck’ is being done.  For similar reasons, the recipe shouldn’t
assume that the subdirectories put into the distribution directory as
effect of having them listed in ‘EXTRA_DIST’ are writable.  So, if the
‘dist-hook’ recipe wants to modify the content of an existing file (or
‘EXTRA_DIST’ subdirectory) in the distribution directory, it should
explicitly to make it writable first:

     EXTRA_DIST = README doc
     dist-hook:
             chmod u+w $(distdir)/README $(distdir)/doc
             echo "Distribution date: `date`" >> README
             rm -f $(distdir)/doc/HACKING

   Two variables that come handy when writing ‘dist-hook’ rules are
‘$(distdir)’ and ‘$(top_distdir)’.

   ‘$(distdir)’ points to the directory where the ‘dist’ rule will copy
files from the current directory before creating the tarball.  If you
are at the top-level directory, then ‘distdir = $(PACKAGE)-$(VERSION)’.
When used from subdirectory named ‘foo/’, then ‘distdir =
../$(PACKAGE)-$(VERSION)/foo’.  ‘$(distdir)’ can be a relative or
absolute path, do not assume any form.

   ‘$(top_distdir)’ always points to the root directory of the
distributed tree.  At the top-level it’s equal to ‘$(distdir)’.  In the
‘foo/’ subdirectory ‘top_distdir = ../$(PACKAGE)-$(VERSION)’.
‘$(top_distdir)’ too can be a relative or absolute path.

   Note that when packages are nested using ‘AC_CONFIG_SUBDIRS’ (*note
Subpackages::), then ‘$(distdir)’ and ‘$(top_distdir)’ are relative to
the package where ‘make dist’ was run, not to any sub-packages involved.


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.  Simplifying a bit, we can
say this rule first makes a distribution, and then, _operating from it_,
takes the following steps:
   • tries to do a ‘VPATH’ build (*note VPATH Builds::), with the
     ‘srcdir’ and all its content made _read-only_;
   • runs the test suite (with ‘make check’) on this fresh build;
   • installs the package in a temporary directory (with ‘make
     install’), and tries runs the test suite on the resulting
     installation (with ‘make installcheck’);
   • checks that the package can be correctly uninstalled (by ‘make
     uninstall’) and cleaned (by ‘make distclean’);
   • finally, makes another tarball to ensure the distribution is
     self-contained.

   All of these actions are performed in a temporary directory.  Please
note that the exact location and the exact structure of such a directory
(where the read-only sources are placed, how the temporary build and
install directories are named and how deeply they are nested, etc.)  is
to be considered an implementation detail, which can change at any time;
so do not reply on it.

DISTCHECK_CONFIGURE_FLAGS
-------------------------

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’.  It’s worth nothing that ‘make distcheck’ needs
complete control over the ‘configure’ options ‘--srcdir’ and ‘--prefix’,
so those options cannot be overridden by ‘AM_DISTCHECK_CONFIGURE_FLAGS’
nor by ‘DISTCHECK_CONFIGURE_FLAGS’.

   Also note that 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’".

distcheck-hook
--------------

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.

distcleancheck
--------------

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 Errors with distclean::), make sure
you read it before playing with ‘distcleancheck_listfiles’.

distuninstallcheck
------------------

‘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-gzip’
     Generate a ‘gzip’ tar archive of the distribution.  This is the
     only format enabled by default.

‘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-lzip’
     Generate an ‘lzip’ tar archive of the distribution.  ‘lzip’
     archives are frequently smaller than ‘bzip2’-compressed archives.

‘dist-xz’
     Generate an ‘xz’ tar archive of the distribution.  ‘xz’ archives
     are frequently smaller than ‘bzip2’-compressed archives.  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=-ve’.

‘dist-zip’
     Generate a ‘zip’ archive of the distribution.

‘dist-tarZ’
     Generate a tar archive of the distribution, compressed with the
     historical (and obsolescent) program ‘compress’.  This option is
     deprecated, and it and the corresponding functionality will be
     removed altogether in Automake 2.0.

‘dist-shar’
     Generate a ‘shar’ archive of the distribution.  This format archive
     is obsolescent, and use of this option is deprecated.  It and the
     corresponding functionality will be removed altogether in Automake
     2.0.

   The rule ‘dist’ (and its historical synonym ‘dist-all’) will create
archives in all the enabled formats (*note List of Automake options::
for how to change this list).  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 can generate code to handle two kinds of test suites.  One is
based on integration with the ‘dejagnu’ framework.  The other (and most
used) form is based on the use of generic test scripts, and its
activation is triggered by the definition of the special ‘TESTS’
variable.  This second form allows for various degrees of sophistication
and customization; in particular, it allows for concurrent execution of
test scripts, use of established test protocols such as TAP, and
definition of custom test drivers and test runners.

In either case, the testsuite is invoked via ‘make check’.

* Menu:

* Generalities about Testing::  Concepts and terminology about testing
* Simple Tests::                Listing test scripts in ‘TESTS’
* Custom Test Drivers::         Writing and using custom test drivers
* Using the TAP test protocol:: Integrating test scripts that use the TAP protocol
* DejaGnu Tests::               Interfacing with the ‘dejagnu’ testing framework
* Install Tests::               Running tests on installed packages


File: automake.info,  Node: Generalities about Testing,  Next: Simple Tests,  Up: Tests

15.1 Generalities about Testing
===============================

The purpose of testing is to determine whether a program or system
behaves as expected (e.g., known inputs produce the expected outputs,
error conditions are correctly handled or reported, and older bugs do
not resurface).

   The minimal unit of testing is usually called _test case_, or simply
_test_.  How a test case is defined or delimited, and even what exactly
_constitutes_ a test case, depends heavily on the testing paradigm
and/or framework in use, so we won’t attempt any more precise
definition.  The set of the test cases for a given program or system
constitutes its _testsuite_.

   A _test harness_ (also _testsuite harness_) is a program or software
component that executes all (or part of) the defined test cases,
analyzes their outcomes, and report or register these outcomes
appropriately.  Again, the details of how this is accomplished (and how
the developer and user can influence it or interface with it) varies
wildly, and we’ll attempt no precise definition.

   A test is said to _pass_ when it can determine that the condition or
behaviour it means to verify holds, and is said to _fail_ when it can
determine that such condition of behaviour does _not_ hold.

   Sometimes, tests can rely on non-portable tools or prerequisites, or
simply make no sense on a given system (for example, a test checking a
Windows-specific feature makes no sense on a GNU/Linux system).  In this
case, accordingly to the definition above, the tests can neither be
considered passed nor failed; instead, they are _skipped_ – i.e., they
are not run, or their result is anyway ignored for what concerns the
count of failures an successes.  Skips are usually explicitly reported
though, so that the user will be aware that not all of the testsuite has
really run.

   It’s not uncommon, especially during early development stages, that
some tests fail for known reasons, and that the developer doesn’t want
to tackle these failures immediately (this is especially true when the
failing tests deal with corner cases).  In this situation, the better
policy is to declare that each of those failures is an _expected
failure_ (or _xfail_).  In case a test that is expected to fail ends up
passing instead, many testing environments will flag the result as a
special kind of failure called _unexpected pass_ (or _xpass_).

   Many testing environments and frameworks distinguish between test
failures and hard errors.  As we’ve seen, a test failure happens when
some invariant or expected behaviour of the software under test is not
met.  An _hard error_ happens when e.g., the set-up of a test case
scenario fails, or when some other unexpected or highly undesirable
condition is encountered (for example, the program under test
experiences a segmentation fault).


File: automake.info,  Node: Simple Tests,  Next: Custom Test Drivers,  Prev: Generalities about Testing,  Up: Tests

15.2 Simple Tests
=================

* Menu:

* Scripts-based Testsuites::    Automake-specific concepts and terminology
* Serial Test Harness::         Older (and discouraged) serial test harness
* Parallel Test Harness::       Generic concurrent test harness


File: automake.info,  Node: Scripts-based Testsuites,  Next: Serial Test Harness,  Up: Simple Tests

15.2.1 Scripts-based Testsuites
-------------------------------

If the special variable ‘TESTS’ is defined, its value is taken to be a
list of programs or scripts to run in order to do the testing.  Under
the appropriate circumstances, it’s possible for ‘TESTS’ to list also
data files to be passed to one or more test scripts defined by different
means (the so-called “log compilers”, *note Parallel Test Harness::).

   Test scripts can be executed serially or concurrently.  Automake
supports both these kinds of test execution, with the parallel test
harness being the default.  The concurrent test harness relies on the
concurrence capabilities (if any) offered by the underlying ‘make’
implementation, and can thus only be as good as those are.

   By default, only the exit statuses of the test scripts are considered
when determining the testsuite outcome.  But Automake allows also the
use of more complex test protocols, either standard (*note Using the TAP
test protocol::) or custom (*note Custom Test Drivers::).  Note that you
can’t enable such protocols when the serial harness is used, though.  In
the rest of this section we are going to concentrate mostly on
protocol-less tests, since we cover test protocols in a later section
(again, *note Custom Test Drivers::).

   When no test protocol is in use, an exit status of 0 from a test
script will denote a success, an exit status of 77 a skipped test, an
exit status of 99 an hard error, and any other exit status will denote a
failure.

   You may define the variable ‘XFAIL_TESTS’ to a list of tests (usually
a subset of ‘TESTS’) that are expected to fail; this will effectively
reverse the result of those tests (with the provision that skips and
hard errors remain untouched).  You may also instruct the testsuite
harness to treat hard errors like simple failures, by defining the
‘DISABLE_HARD_ERRORS’ make variable to a nonempty value.

   Note however that, for tests based on more complex test protocols,
the exact effects of ‘XFAIL_TESTS’ and ‘DISABLE_HARD_ERRORS’ might
change, or they might even have no effect at all (for example, in tests
using TAP, there is not way to disable hard errors, and the
‘DISABLE_HARD_ERRORS’ variable has no effect on them).

   The result of each test case run by the scripts in ‘TESTS’ will be
printed on standard output, along with the test name.  For test
protocols that allow more test cases per test script (such as TAP), a
number, identifier and/or brief description specific for the single test
case is expected to be printed in addition to the name of the test
script.  The possible results (whose meanings should be clear from the
previous *note Generalities about Testing::) are ‘PASS’, ‘FAIL’, ‘SKIP’,
‘XFAIL’, ‘XPASS’ and ‘ERROR’.  Here is an example of output from an
hypothetical testsuite that uses both plain and TAP tests:
     PASS: foo.sh
     PASS: zardoz.tap 1 - Daemon started
     PASS: zardoz.tap 2 - Daemon responding
     SKIP: zardoz.tap 3 - Daemon uses /proc # SKIP /proc is not mounted
     PASS: zardoz.tap 4 - Daemon stopped
     SKIP: bar.sh
     PASS: mu.tap 1
     XFAIL: mu.tap 2 # TODO frobnication not yet implemented

A testsuite summary (expected to report at least the number of run,
skipped and failed tests) will be printed at the end of the testsuite
run.

   If the standard output is connected to a capable terminal, then the
test results and the summary are colored appropriately.  The developer
and the user can disable colored output by setting the ‘make’ variable
‘AM_COLOR_TESTS=no’; the user can in addition force colored output even
without a connecting terminal with ‘AM_COLOR_TESTS=always’.  It’s also
worth noting that some ‘make’ implementations, when used in parallel
mode, have slightly different semantics (*note (autoconf)Parallel
make::), which can break the automatic detection of a connection to a
capable terminal.  If this is the case, the user will have to resort to
the use of ‘AM_COLOR_TESTS=always’ in order to have the testsuite output
colorized.

   Test programs that need data files should look for them in ‘srcdir’
(which is both a make variable and an environment variable made
available to the tests), so that 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::).

   The ‘AM_TESTS_ENVIRONMENT’ and ‘TESTS_ENVIRONMENT’ variables can be
used to run initialization code and set environment variables for the
test scripts.  The former variable is developer-reserved, and can be
defined in the ‘Makefile.am’, while the latter is reserved for the user,
which can employ it to extend or override the settings in the former;
for this to work portably, however, the contents of a non-empty
‘AM_TESTS_ENVIRONMENT’ _must_ be terminated by a semicolon.

   The ‘AM_TESTS_FD_REDIRECT’ variable can be used to define file
descriptor redirections for the test scripts.  One might think that
‘AM_TESTS_ENVIRONMENT’ could be used for this purpose, but experience
has shown that doing so portably is practically impossible.  The main
hurdle is constituted by Korn shells, which usually set the
close-on-exec flag on file descriptors opened with the ‘exec’ builtin,
thus rendering an idiom like ‘AM_TESTS_ENVIRONMENT = exec 9>&2;’
ineffectual.  This issue also affects some Bourne shells, such as the
HP-UX’s ‘/bin/sh’,

     AM_TESTS_ENVIRONMENT = \
     ## Some environment initializations are kept in a separate shell
     ## file 'tests-env.sh', which can make it easier to also run tests
     ## from the command line.
       . $(srcdir)/tests-env.sh; \
     ## On Solaris, prefer more POSIX-compliant versions of the standard
     ## tools by default.
       if test -d /usr/xpg4/bin; then \
         PATH=/usr/xpg4/bin:$$PATH; export PATH; \
       fi;
     ## With this, the test scripts will be able to print diagnostic
     ## messages to the original standard error stream, even if the test
     ## driver redirects the stderr of the test scripts to a log file
     ## before executing them.
     AM_TESTS_FD_REDIRECT = 9>&2

Note however that ‘AM_TESTS_ENVIRONMENT’ is, for historical and
implementation reasons, _not_ supported by the serial harness (*note
Serial Test Harness::).

   Automake ensures that each file listed in ‘TESTS’ is built before it
is 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: Serial Test Harness,  Next: Parallel Test Harness,  Prev: Scripts-based Testsuites,  Up: Simple Tests

15.2.2 Older (and discouraged) serial test harness
--------------------------------------------------

First, note that today the use of this harness is strongly discouraged
in favour of the parallel test harness (*note Parallel Test Harness::).
Still, there are _few_ situations when the advantages offered by the
parallel harness are irrelevant, and when test concurrency can even
cause tricky problems.  In those cases, it might make sense to still use
the serial harness, for simplicity and reliability (we still suggest
trying to give the parallel harness a shot though).

   The serial test harness is enabled by the Automake option
‘serial-tests’.  It operates by simply running the tests serially, one
at the time, without any I/O redirection.  It’s up to the user to
implement logging of tests’ output, if that’s requited or desired.

   For historical and implementation reasons, the ‘AM_TESTS_ENVIRONMENT’
variable is _not_ supported by this harness (it will be silently ignored
if defined); only ‘TESTS_ENVIRONMENT’ is, and it is to be considered a
developer-reserved variable.  This is done so that, when using the
serial harness, ‘TESTS_ENVIRONMENT’ can be defined to an invocation of
an interpreter through which the tests are to be run.  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

It’s important to note that the use of ‘TESTS_ENVIRONMENT’ endorsed here
would be _invalid_ with the parallel harness.  That harness provides a
more elegant way to achieve the same effect, with the further benefit of
freeing the ‘TESTS_ENVIRONMENT’ variable for the user (*note Parallel
Test Harness::).

   Another, less serious limit of the serial harness is that it doesn’t
really distinguish between simple failures and hard errors; this is due
to historical reasons only, and might be fixed in future Automake
versions.


File: automake.info,  Node: Parallel Test Harness,  Prev: Serial Test Harness,  Up: Simple Tests

15.2.3 Parallel Test Harness
----------------------------

By default, Automake generated a parallel (concurrent) test harness.  It
features automatic collection of the test scripts output in ‘.log’
files, concurrent execution of tests with ‘make -j’, specification of
inter-test dependencies, lazy reruns of tests that have not completed in
a prior run, and hard errors for exceptional failures.

   The parallel test harness operates by defining a set of ‘make’ rules
that run the test scripts listed in ‘TESTS’, and, for each such script,
save its output in a corresponding ‘.log’ file and its results (and
other “metadata”, *note API for Custom Test Drivers::) in a
corresponding ‘.trs’ (as in Test ReSults) file.  The ‘.log’ file will
contain all the output emitted by the test on its standard output and
its standard error.  The ‘.trs’ file will contain, among the other
things, the results of the test cases run by the script.

   The parallel test harness will also create a summary log file,
‘TEST_SUITE_LOG’, which defaults to ‘test-suite.log’ and requires a
‘.log’ suffix.  This file depends upon all the ‘.log’ and ‘.trs’ files
created for the test scripts listed in ‘TESTS’.

   As with the serial harness 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.

   Each couple of ‘.log’ and ‘.trs’ files 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.

   It is important to note that, due to current limitations (unlikely to
be lifted), configure substitutions in the definition of ‘TESTS’ can
only work if they will expand to a list of tests that have a suffix
listed in ‘TEST_EXTENSIONS’.

   For tests that match an extension ‘.EXT’ listed in ‘TEST_EXTENSIONS’,
you can provide a custom “test runner” 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 runner.  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 ‘foo.trs’, ‘bar.trs’ and ‘baz.trs’ files
will be automatically produced as a side-effect.

   It’s important to note that, differently from what we’ve seen for the
serial test harness (*note Serial Test Harness::), the
‘AM_TESTS_ENVIRONMENT’ and ‘TESTS_ENVIRONMENT’ variables _cannot_ be use
to define a custom test runner; the ‘LOG_COMPILER’ and ‘LOG_FLAGS’ (or
their extension-specific counterparts) should be used instead:

     ## This is WRONG!
     AM_TESTS_ENVIRONMENT = PERL5LIB='$(srcdir)/lib' $(PERL) -Mstrict -w

     ## Do this instead.
     AM_TESTS_ENVIRONMENT = PERL5LIB='$(srcdir)/lib'; export PERL5LIB;
     LOG_COMPILER = $(PERL)
     AM_LOG_FLAGS = -Mstrict -w

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

   • You can set the ‘TESTS’ variable.  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 harness removes all old per-test ‘.log’ and
     ‘.trs’ files before it starts running tests to regenerate them.
     The variable ‘RECHECK_LOGS’ contains the set of ‘.log’ (and, by
     implication, ‘.trs’) 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 harness.

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 (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: Custom Test Drivers,  Next: Using the TAP test protocol,  Prev: Simple Tests,  Up: Tests

15.3 Custom Test Drivers
========================

* Menu:

* Overview of Custom Test Drivers Support::
* Declaring Custom Test Drivers::
* API for Custom Test Drivers::


File: automake.info,  Node: Overview of Custom Test Drivers Support,  Next: Declaring Custom Test Drivers,  Up: Custom Test Drivers

15.3.1 Overview of Custom Test Drivers Support
----------------------------------------------

Starting from Automake version 1.12, the parallel test harness allows
the package authors to use third-party custom test drivers, in case the
default ones are inadequate for their purposes, or do not support their
testing protocol of choice.

   A custom test driver is expected to properly run the test programs
passed to it (including the command-line arguments passed to those
programs, if any), to analyze their execution and outcome, to create the
‘.log’ and ‘.trs’ files associated to these test runs, and to display
the test results on the console.  It is responsibility of the author of
the test driver to ensure that it implements all the above steps
meaningfully and correctly; Automake isn’t and can’t be of any help
here.  On the other hand, the Automake-provided code for testsuite
summary generation offers support for test drivers allowing several test
results per test script, if they take care to register such results
properly (*note Log files generation and test results recording::).

   The exact details of how test scripts’ results are to be determined
and analyzed is left to the individual drivers.  Some drivers might only
consider the test script exit status (this is done for example by the
default test driver used by the parallel test harness, described in the
previous section).  Other drivers might implement more complex and
advanced test protocols, which might require them to parse and
interpreter the output emitted by the test script they’re running
(examples of such protocols are TAP and SubUnit).

   It’s very important to note that, even when using custom test
drivers, most of the infrastructure described in the previous section
about the parallel harness remains in place; this includes:

   • list of test scripts defined in ‘TESTS’, and overridable at runtime
     through the redefinition of ‘TESTS’ or ‘TEST_LOGS’;
   • concurrency through the use of ‘make’’s option ‘-j’;
   • per-test ‘.log’ and ‘.trs’ files, and generation of a summary
     ‘.log’ file from them;
   • ‘recheck’ target, ‘RECHECK_LOGS’ variable, and lazy reruns of
     tests;
   • inter-test dependencies;
   • support for ‘check_*’ variables (‘check_PROGRAMS’,
     ‘check_LIBRARIES’, ...);
   • use of ‘VERBOSE’ environment variable to get verbose output on
     testsuite failures;
   • definition and honoring of ‘TESTS_ENVIRONMENT’,
     ‘AM_TESTS_ENVIRONMENT’ and ‘AM_TESTS_FD_REDIRECT’ variables;
   • definition of generic and extension-specific ‘LOG_COMPILER’ and
     ‘LOG_FLAGS’ variables.

On the other hand, the exact semantics of how (and if) testsuite output
colorization, ‘XFAIL_TESTS’, and hard errors are supported and handled
is left to the individual test drivers.


File: automake.info,  Node: Declaring Custom Test Drivers,  Next: API for Custom Test Drivers,  Prev: Overview of Custom Test Drivers Support,  Up: Custom Test Drivers

15.3.2 Declaring Custom Test Drivers
------------------------------------

Custom testsuite drivers are declared by defining the make variables
‘LOG_DRIVER’ or ‘EXT_LOG_DRIVER’ (where EXT must be declared in
‘TEST_EXTENSIONS’).  They must be defined to programs or scripts that
will be used to drive the execution, logging, and outcome report of the
tests with corresponding extensions (or of those with no registered
extension in the case of ‘LOG_DRIVER’).  Clearly, multiple distinct test
drivers can be declared in the same ‘Makefile.am’.  Note moreover that
the ‘LOG_DRIVER’ variables are _not_ a substitute for the ‘LOG_COMPILER’
variables: the two sets of variables can, and often do, usefully and
legitimately coexist.

   The developer-reserved variable ‘AM_LOG_DRIVER_FLAGS’ and the
user-reserved variable ‘LOG_DRIVER_FLAGS’ can be used to define flags
that will be passed to each invocation of ‘LOG_DRIVER’, with the
user-defined flags obviously taking precedence over the
developer-reserved ones.  Similarly, for each extension EXT declared in
‘TEST_EXTENSIONS’, flags listed in ‘AM_EXT_LOG_DRIVER_FLAGS’ and
‘EXT_LOG_DRIVER_FLAGS’ will be passed to invocations of
‘EXT_LOG_DRIVER’.


File: automake.info,  Node: API for Custom Test Drivers,  Prev: Declaring Custom Test Drivers,  Up: Custom Test Drivers

15.3.3 API for Custom Test Drivers
----------------------------------

Note that _the APIs described here are still highly experimental_, and
will very likely undergo tightenings and likely also extensive changes
in the future, to accommodate for new features or to satisfy additional
portability requirements.

   The main characteristic of these APIs is that they are designed to
share as much infrastructure, semantics, and implementation details as
possible with the parallel test harness and its default driver.

* Menu:

* Command-line arguments for test drivers::
* Log files generation and test results recording::
* Testsuite progress output::


File: automake.info,  Node: Command-line arguments for test drivers,  Next: Log files generation and test results recording,  Up: API for Custom Test Drivers

15.3.3.1 Command-line arguments for test drivers
................................................

A custom driver can rely on various command-line options and arguments
being passed to it automatically by the Automake-generated test harness.
It is _mandatory_ that it understands all of them (even if the exact
interpretation of the associated semantics can legitimately change
between a test driver and another, and even be a no-op in some drivers).

Here is the list of options:

‘--test-name=NAME’
     The name of the test, with VPATH prefix (if any) removed.  This can
     have a suffix and a directory component (as in e.g.,
     ‘sub/foo.test’), and is mostly meant to be used in console reports
     about testsuite advancements and results (*note Testsuite progress
     output::).
‘--log-file=PATH.log’
     The ‘.log’ file the test driver must create (*note Basics of test
     metadata::).  If it has a directory component (as in e.g.,
     ‘sub/foo.log’), the test harness will ensure that such directory
     exists _before_ the test driver is called.
‘--trs-file=PATH.trs’
     The ‘.trs’ file the test driver must create (*note Basics of test
     metadata::).  If it has a directory component (as in e.g.,
     ‘sub/foo.trs’), the test harness will ensure that such directory
     exists _before_ the test driver is called.
‘--color-tests={yes|no}’
     Whether the console output should be colorized or not (*note Simple
     tests and color-tests::, to learn when this option gets activated
     and when it doesn’t).
‘--expect-failure={yes|no}’
     Whether the tested program is expected to fail.
‘--enable-hard-errors={yes|no}’
     Whether “hard errors” in the tested program should be treated
     differently from normal failures or not (the default should be
     ‘yes’).  The exact meaning of “hard error” is highly dependent from
     the test protocols or conventions in use.
‘--’
     Explicitly terminate the list of options.

The first non-option argument passed to the test driver is the program
to be run, and all the following ones are command-line options and
arguments for this program.

   Note that the exact semantics attached to the ‘--color-tests’,
‘--expect-failure’ and ‘--enable-hard-errors’ options are left up to the
individual test drivers.  Still, having a behaviour compatible or at
least similar to that provided by the default driver is advised, as that
would offer a better consistency and a more pleasant user experience.


File: automake.info,  Node: Log files generation and test results recording,  Next: Testsuite progress output,  Prev: Command-line arguments for test drivers,  Up: API for Custom Test Drivers

15.3.3.2 Log files generation and test results recording
........................................................

The test driver must correctly generate the files specified by the
‘--log-file’ and ‘--trs-file’ option (even when the tested program fails
or crashes).

   The ‘.log’ file should ideally contain all the output produced by the
tested program, plus optionally other information that might facilitate
debugging or analysis of bug reports.  Apart from that, its format is
basically free.

   The ‘.trs’ file is used to register some metadata through the use of
custom reStructuredText fields.  This metadata is expected to be
employed in various ways by the parallel test harness; for example, to
count the test results when printing the testsuite summary, or to decide
which tests to re-run upon ‘make recheck’.  Unrecognized metadata in a
‘.trs’ file is currently ignored by the harness, but this might change
in the future.  The list of currently recognized metadata follows.

‘:test-result:’
     The test driver must use this field to register the results of
     _each_ test case run by a test script file.  Several
     ‘:test-result:’ fields can be present in the same ‘.trs’ file; this
     is done in order to support test protocols that allow a single test
     script to run more test cases.

     The only recognized test results are currently ‘PASS’, ‘XFAIL’,
     ‘SKIP’, ‘FAIL’, ‘XPASS’ and ‘ERROR’.  These results, when declared
     with ‘:test-result:’, can be optionally followed by text holding
     the name and/or a brief description of the corresponding test; the
     harness will ignore such extra text when generating
     ‘test-suite.log’ and preparing the testsuite summary.

‘:recheck:’
     If this field is present and defined to ‘no’, then the
     corresponding test script will _not_ be run upon a ‘make recheck’.
     What happens when two or more ‘:recheck:’ fields are present in the
     same ‘.trs’ file is undefined behaviour.

‘:copy-in-global-log:’
     If this field is present and defined to ‘no’, then the content of
     the ‘.log’ file will _not_ be copied into the global
     ‘test-suite.log’.  We allow to forsake such copying because, while
     it can be useful in debugging and analysis of bug report, it can
     also be just a waste of space in normal situations, e.g., when a
     test script is successful.  What happens when two or more
     ‘:copy-in-global-log:’ fields are present in the same ‘.trs’ file
     is undefined behaviour.

‘:test-global-result:’
     This is used to declare the "global result" of the script.
     Currently, the value of this field is needed only to be reported
     (more or less verbatim) in the generated global log file
     ‘$(TEST_SUITE_LOG)’, so it’s quite free-form.  For example, a test
     script which run 10 test cases, 6 of which pass and 4 of which are
     skipped, could reasonably have a ‘PASS/SKIP’ value for this field,
     while a test script which run 19 successful tests and one failed
     test could have an ‘ALMOST PASSED’ value.  What happens when two or
     more ‘:test-global-result:’ fields are present in the same ‘.trs’
     file is undefined behaviour.

Let’s see a small example.  Assume a ‘.trs’ file contains the following
lines:

     :test-result: PASS server starts
     :global-log-copy: no
     :test-result: PASS HTTP/1.1 request
     :test-result: FAIL HTTP/1.0 request
     :recheck: yes
     :test-result: SKIP HTTPS request (TLS library wasn't available)
     :test-result: PASS server stops

Then the corresponding test script will be re-run by ‘make check’, will
contribute with _five_ test results to the testsuite summary (three of
these tests being successful, one failed, and one skipped), and the
content of the corresponding ‘.log’ file will _not_ be copied in the
global log file ‘test-suite.log’.


File: automake.info,  Node: Testsuite progress output,  Prev: Log files generation and test results recording,  Up: API for Custom Test Drivers

15.3.3.3 Testsuite progress output
..................................

A custom test driver also has the task of displaying, on the standard
output, the test results as soon as they become available.  Depending on
the protocol in use, it can also display the reasons for failures and
skips, and, more generally, any useful diagnostic output (but remember
that each line on the screen is precious, so that cluttering the screen
with overly verbose information is bad idea).  The exact format of this
progress output is left up to the test driver; in fact, a custom test
driver might _theoretically_ even decide not to do any such report,
leaving it all to the testsuite summary (that would be a very lousy
idea, of course, and serves only to illustrate the flexibility that is
granted here).

   Remember that consistency is good; so, if possible, try to be
consistent with the output of the built-in Automake test drivers,
providing a similar “look & feel”.  In particular, the testsuite
progress output should be colorized when the ‘--color-tests’ is passed
to the driver.  On the other end, if you are using a known and
widespread test protocol with well-established implementations, being
consistent with those implementations’ output might be a good idea too.


File: automake.info,  Node: Using the TAP test protocol,  Next: DejaGnu Tests,  Prev: Custom Test Drivers,  Up: Tests

15.4 Using the TAP test protocol
================================

* Menu:

* Introduction to TAP::
* Use TAP with the Automake test harness::
* Incompatibilities with other TAP parsers and drivers::
* Links and external resources on TAP::


File: automake.info,  Node: Introduction to TAP,  Next: Use TAP with the Automake test harness,  Up: Using the TAP test protocol

15.4.1 Introduction to TAP
--------------------------

TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules or programs and a test harness.  The tests (also
called “TAP producers” in this context) write test results in a simple
format on standard output; a test harness (also called “TAP consumer”)
will parse and interpret these results, and properly present them to the
user, and/or register them for later analysis.  The exact details of how
this is accomplished can vary among different test harnesses.  The
Automake harness will present the results on the console in the usual
fashion (*note Testsuite progress on console::), and will use the ‘.trs’
files (*note Basics of test metadata::) to store the test results and
related metadata.  Apart from that, it will try to remain as much
compatible as possible with pre-existing and widespread utilities, such
as the ‘prove’ utility
(http://search.cpan.org/~andya/Test-Harness/bin/prove), at least for the
simpler usages.

   TAP started its life as part of the test harness for Perl, but today
it has been (mostly) standardized, and has various independent
implementations in different languages; among them, C, C++, Perl,
Python, PHP, and Java.  For a semi-official specification of the TAP
protocol, please refer to the documentation of ‘Test::Harness::TAP’
(http://search.cpan.org/~petdance/Test-Harness/lib/Test/Harness/TAP.pod).

   The most relevant real-world usages of TAP are obviously in the
testsuites of ‘perl’ and of many perl modules.  Still, also other
important third-party packages, such as ‘git’ (http://git-scm.com/), use
TAP in their testsuite.


File: automake.info,  Node: Use TAP with the Automake test harness,  Next: Incompatibilities with other TAP parsers and drivers,  Prev: Introduction to TAP,  Up: Using the TAP test protocol

15.4.2 Use TAP with the Automake test harness
---------------------------------------------

Currently, the TAP driver that comes with Automake requires some by-hand
steps on the developer’s part (this situation should hopefully be
improved in future Automake versions).  You’ll have to grab the
‘tap-driver.sh’ script from the Automake distribution by hand, copy it
in your source tree, and use the Automake support for third-party test
drivers to instruct the harness to use the ‘tap-driver.sh’ script and
the awk program found by ‘AM_INIT_AUTOMAKE’ to run your TAP-producing
tests.  See the example below for clarification.

   Apart from the options common to all the Automake test drivers (*note
Command-line arguments for test drivers::), the ‘tap-driver.sh’ supports
the following options, whose names are chosen for enhanced compatibility
with the ‘prove’ utility.

‘--ignore-exit’
     Causes the test driver to ignore the exit status of the test
     scripts; by default, the driver will report an error if the script
     exits with a non-zero status.  This option has effect also on
     non-zero exit statuses due to termination by a signal.
‘--comments’
     Instruct the test driver to display TAP diagnostic (i.e., lines
     beginning with the ‘#’ character) in the testsuite progress output
     too; by default, TAP diagnostic is only copied to the ‘.log’ file.
‘--no-comments’
     Revert the effects of ‘--comments’.
‘--merge’
     Instruct the test driver to merge the test scripts’ standard error
     into their standard output.  This is necessary if you want to
     ensure that diagnostics from the test scripts are displayed in the
     correct order relative to test results; this can be of great help
     in debugging (especially if your test scripts are shell scripts run
     with shell tracing active).  As a downside, this option might cause
     the test harness to get confused if anything that appears on
     standard error looks like a test result.
‘--no-merge’
     Revert the effects of ‘--merge’.
‘--diagnostic-string=STRING’
     Change the string that introduces TAP diagnostic from the default
     value of “‘#’” to ‘STRING’.  This can be useful if your TAP-based
     test scripts produce verbose output on which they have limited
     control (because, say, the output comes from other tools invoked in
     the scripts), and it might contain text that gets spuriously
     interpreted as TAP diagnostic: such an issue can be solved by
     redefining the string that activates TAP diagnostic to a value you
     know won’t appear by chance in the tests’ output.  Note however
     that this feature is non-standard, as the “official” TAP protocol
     does not allow for such a customization; so don’t use it if you can
     avoid it.

Here is an example of how the TAP driver can be set up and used.

     % cat configure.ac
     AC_INIT([GNU Try Tap], [1.0], [bug-automake@gnu.org])
     AC_CONFIG_AUX_DIR([build-aux])
     AM_INIT_AUTOMAKE([foreign -Wall -Werror])
     AC_CONFIG_FILES([Makefile])
     AC_REQUIRE_AUX_FILE([tap-driver.sh])
     AC_OUTPUT

     % cat Makefile.am
     TEST_LOG_DRIVER = env AM_TAP_AWK='$(AWK)' $(SHELL) \
                       $(top_srcdir)/build-aux/tap-driver.sh
     TESTS = foo.test bar.test baz.test
     EXTRA_DIST = $(TESTS)

     % cat foo.test
     #!/bin/sh
     echo 1..4 # Number of tests to be executed.
     echo 'ok 1 - Swallows fly'
     echo 'not ok 2 - Caterpillars fly # TODO metamorphosis in progress'
     echo 'ok 3 - Pigs fly # SKIP not enough acid'
     echo '# I just love word plays ...'
     echo 'ok 4 - Flies fly too :-)'

     % cat bar.test
     #!/bin/sh
     echo 1..3
     echo 'not ok 1 - Bummer, this test has failed.'
     echo 'ok 2 - This passed though.'
     echo 'Bail out! Ennui kicking in, sorry...'
     echo 'ok 3 - This will not be seen.'

     % cat baz.test
     #!/bin/sh
     echo 1..1
     echo ok 1
     # Exit with error, even if all the tests have been successful.
     exit 7

     % cp PREFIX/share/automake-APIVERSION/tap-driver.sh .
     % autoreconf -vi && ./configure && make check
     ...
     PASS: foo.test 1 - Swallows fly
     XFAIL: foo.test 2 - Caterpillars fly # TODO metamorphosis in progress
     SKIP: foo.test 3 - Pigs fly # SKIP not enough acid
     PASS: foo.test 4 - Flies fly too :-)
     FAIL: bar.test 1 - Bummer, this test has failed.
     PASS: bar.test 2 - This passed though.
     ERROR: bar.test - Bail out! Ennui kicking in, sorry...
     PASS: baz.test 1
     ERROR: baz.test - exited with status 7
     ...
     Please report to bug-automake@gnu.org
     ...
     % echo exit status: $?
     exit status: 1

     % env TEST_LOG_DRIVER_FLAGS='--comments --ignore-exit' \
           TESTS='foo.test baz.test' make -e check
     ...
     PASS: foo.test 1 - Swallows fly
     XFAIL: foo.test 2 - Caterpillars fly # TODO metamorphosis in progress
     SKIP: foo.test 3 - Pigs fly # SKIP not enough acid
     # foo.test: I just love word plays...
     PASS: foo.test 4 - Flies fly too :-)
     PASS: baz.test 1
     ...
     % echo exit status: $?
     exit status: 0


File: automake.info,  Node: Incompatibilities with other TAP parsers and drivers,  Next: Links and external resources on TAP,  Prev: Use TAP with the Automake test harness,  Up: Using the TAP test protocol

15.4.3 Incompatibilities with other TAP parsers and drivers
-----------------------------------------------------------

For implementation or historical reasons, the TAP driver and harness as
implemented by Automake have some minors incompatibilities with the
mainstream versions, which you should be aware of.

   • A ‘Bail out!’ directive doesn’t stop the whole testsuite, but only
     the test script it occurs in.  This doesn’t follow TAP
     specifications, but on the other hand it maximizes compatibility
     (and code sharing) with the “hard error” concept of the default
     testsuite driver.
   • The ‘version’ and ‘pragma’ directives are not supported.
   • The ‘--diagnostic-string’ option of our driver allows to modify the
     string that introduces TAP diagnostic from the default value of
     “‘#’”.  The standard TAP protocol has currently no way to allow
     this, so if you use it your diagnostic will be lost to more
     compliant tools like ‘prove’ and ‘Test::Harness’
   • And there are probably some other small and yet undiscovered
     incompatibilities, especially in corner cases or with rare usages.


File: automake.info,  Node: Links and external resources on TAP,  Prev: Incompatibilities with other TAP parsers and drivers,  Up: Using the TAP test protocol

15.4.4 Links and external resources on TAP
------------------------------------------

Here are some links to more extensive official or third-party
documentation and resources about the TAP protocol and related tools and
libraries.
   •  ‘Test::Harness::TAP’
     (http://search.cpan.org/~petdance/Test-Harness/lib/Test/Harness/TAP.pod),
     the (mostly) official documentation about the TAP format and
     protocol.
   •  ‘prove’ (http://search.cpan.org/~andya/Test-Harness/bin/prove),
     the most famous command-line TAP test driver, included in the
     distribution of ‘perl’ and ‘Test::Harness’
     (http://search.cpan.org/~andya/Test-Harness/lib/Test/Harness.pm).
   • The TAP wiki (http://testanything.org/wiki/index.php/Main_Page).
   • A “gentle introduction” to testing for perl coders:
     ‘Test::Tutorial’
     (http://search.cpan.org/dist/Test-Simple/lib/Test/Tutorial.pod).
   •  ‘Test::Simple’
     (http://search.cpan.org/~mschwern/Test-Simple/lib/Test/Simple.pm)
     and ‘Test::More’
     (http://search.cpan.org/~mschwern/Test-Simple/lib/Test/More.pm),
     the standard perl testing libraries, which are based on TAP.
   • C TAP Harness
     (http://www.eyrie.org/~eagle/software/c-tap-harness/), a C-based
     project implementing both a TAP producer and a TAP consumer.
   • tap4j (http://www.tap4j.org/), a Java-based project implementing
     both a TAP producer and a TAP consumer.


File: automake.info,  Node: DejaGnu Tests,  Next: Install Tests,  Prev: Using the TAP test protocol,  Up: Tests

15.5 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
(dejagnu)Top::.

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

15.6 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 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.  Be also aware that
interactions of this variable with the *note autom4te cache:
(autoconf)Autom4te Cache. are quite problematic and can cause subtle
breakage, so you might want to disable the cache if you want to use
‘CONFIGURE_DEPENDENCIES’.

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

* Menu:

* Options generalities::        Semantics of Automake option
* List of Automake options::    A comprehensive list of Automake options


File: automake.info,  Node: Options generalities,  Next: List of Automake options,  Up: Options

17.1 Options generalities
=========================

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.

   As a general rule, options specified in ‘AUTOMAKE_OPTIONS’ take
precedence over those specified in ‘AM_INIT_AUTOMAKE’, which in turn
take precedence over those specified on the command line.

   Also, some care must be taken about the interactions among strictness
level and warning categories.  As a general rule, strictness-implied
warnings are overridden by those specified by explicit options.  For
example, even if ‘portability’ warnings are disabled by default in
‘foreign’ strictness, an usage like this will end up enabling them:

     AUTOMAKE_OPTIONS = -Wportability foreign

   However, a strictness level specified in a higher-priority context
will override all the explicit warnings specified in a lower-priority
context.  For example, if ‘configure.ac’ contains:

     AM_INIT_AUTOMAKE([-Wportability])

and ‘Makefile.am’ contains:

     AUTOMAKE_OPTIONS = foreign

then ‘portability’ warnings will be _disabled_ in ‘Makefile.am’.


File: automake.info,  Node: List of Automake options,  Prev: Options generalities,  Up: Options

17.2 List of Automake options
=============================

‘gnits’
‘gnu’
‘foreign’

     Set the strictness as appropriate.  The ‘gnits’ option also implies
     options ‘readme-alpha’ and ‘check-news’.

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

‘dejagnu’
     Cause ‘dejagnu’-specific rules to be generated.  *Note DejaGnu
     Tests::.

‘dist-bzip2’
     Hook ‘dist-bzip2’ to ‘dist’.

‘dist-lzip’
     Hook ‘dist-lzip’ to ‘dist’.

‘dist-xz’
     Hook ‘dist-xz’ to ‘dist’.

‘dist-zip’
     Hook ‘dist-zip’ to ‘dist’.

‘dist-shar’
     Hook ‘dist-shar’ to ‘dist’.  Use of this option is deprecated, as
     the ‘shar’ format is obsolescent and problematic.  Support for it
     will be removed altogether in Automake 2.0.

‘dist-tarZ’
     Hook ‘dist-tarZ’ to ‘dist’.  Use of this option is deprecated, as
     the ‘compress’ program is obsolete.  Support for it will be removed
     altogether in Automake 2.0.

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

‘info-in-builddir’
     Instruct Automake to place the generated ‘.info’ files in the
     ‘builddir’ rather than in the ‘srcdir’.  Note that this might make
     VPATH builds with some non-GNU make implementations more brittle.

‘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.  But notice that they will
     remain defined as shell variables in the generated ‘configure’, and
     as make variables in the generated ‘Makefile’; this is deliberate,
     and required for backward compatibility.

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

‘serial-tests’
     Enable the older serial test suite harness for ‘TESTS’ (*note
     Serial Test Harness::, for more information).

‘parallel-tests’
     Enable test suite harness for ‘TESTS’ that can run tests in
     parallel (*note Parallel Test Harness::, for more information).
     This option is only kept for backward-compatibility, since the
     parallel test harness is the default now.

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

‘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 Windows 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’.

‘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-lzip’, ‘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 automake Invocation::).  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 cscope, etags and mkid
* Suffixes::                    Handling new file extensions


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.

   Similarly, the ‘cscope’ rule will create a list of all the source
files in the tree and run ‘cscope’ to build an inverted index database.
The variable ‘CSCOPE’ is the name of the program to invoke (by default
‘cscope’); ‘CSCOPEFLAGS’ and ‘CSCOPE_ARGS’ can be used by the user to
pass additional flags and file names respectively, while
‘AM_CSCOPEFLAGS’ can be used by the ‘Makefile.am’.  Note that,
currently, the Automake-provided ‘cscope’ support, when used in a VPATH
build, might not work well with non-GNU make implementations (especially
with make implementations performing *note VPATH rewrites:
(autoconf)Automatic Rule Rewriting.).

   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,  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: 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’.

   Inside a fragment, the construct ‘%reldir%’ is replaced with the
directory of the fragment relative to the base ‘Makefile.am’.
Similarly, ‘%canon_reldir%’ is replaced with the canonicalized (*note
Canonicalization::) form of ‘%reldir%’.  As a convenience, ‘%D%’ is a
synonym for ‘%reldir%’, and ‘%C%’ is a synonym for ‘%canon_reldir%’.

   A special feature is that if the fragment is in the same directory as
the base ‘Makefile.am’ (i.e., ‘%reldir%’ is ‘.’), then ‘%reldir%’ and
‘%canon_reldir%’ will expand to the empty string as well as eat, if
present, a following slash or underscore respectively.

   Thus, a makefile fragment might look like this:

     bin_PROGRAMS += %reldir%/mumble
     %canon_reldir%_mumble_SOURCES = %reldir%/one.c


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 (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::       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,  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::) we’ll see how Automake can help
in this respect, providing more elaborate and flexible idioms.

   • ‘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,  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’ (for most rules at least).

   To give the gist of what Automake can do in this respect, 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

   For Automake-generated ‘Makefile’s, the user 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 really
wants to make silent rules enabled by default in his own package can do
so by calling ‘AM_SILENT_RULES([yes])’ in ‘configure.ac’.

   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.

   To work at its best, the current implementation of this feature
normally uses nested variable expansion ‘$(VAR1$(V))’, a ‘Makefile’
feature that is not required by POSIX 2008 but is widely supported in
practice.  On the rare ‘make’ implementations that do not support nested
variable expansion, whether rules are silent is always determined at
configure time, and cannot be overridden at make time.  Future versions
of POSIX are likely to require nested variable expansion, so this minor
limitation should go away with time.

   To extend the silent mode to your own rules, you have few 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 silence a recipe unconditionally with ‘@’, and then use the
     predefined variable ‘AM_V_P’ to know whether make is being run in
     silent or verbose mode, adjust the verbose information your recipe
     displays accordingly:

          generate-headers:
                          ... [commands defining a shell variable '$headers'] ...; \
                  if $(AM_V_P); then set -x; else echo " GEN   [headers]"; fi; \
                  rm -f $$headers && generate-header --flags $$headers

   • 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_@AM_V@)
          pkg_verbose_ = $(pkg_verbose_@AM_DEFAULT_V@)
          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: Not Enough,  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: Not Enough,  Next: Distributing,  Prev: Gnits,  Up: Top

23 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

23.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 automake
Invocation::) 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

23.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 of 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

24 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

25 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

26 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 of 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 automake Invocation::).

   It is important to regenerate all of 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: Copying This Manual,  Prev: Upgrading,  Up: Top

27 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
* Errors with distclean::       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

27.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 machine 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 output 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’.

     Calls to such tools are all wrapped into a call to the ‘missing’
     script discussed later (*note maintainer-mode::), so that the user
     will see more descriptive warnings about missing or out-of-date
     tools, and possible suggestions about how to obtain them, rather
     than just some “command not found” error, or (worse) some obscure
     message from some older version of the required tool they happen to
     have installed.

     Maintainers interested in keeping their package buildable from a
     CVS checkout even for those users that lack maintainer-specific
     tools might want to provide an helper script (or to enhance their
     existing bootstrap script) to fix the timestamps after a ‘cvs
     update’ or a ‘git checkout’, to prevent spurious rebuilds.  In case
     of a project committing the Autotools-generated files, as well as
     the generated ‘.info’ files, such script might look something like
     this:

          #!/bin/sh
          # fix-timestamp.sh: prevents useless rebuilds after "cvs update"
          sleep 1
          # aclocal-generated aclocal.m4 depends on locally-installed
          # '.m4' macro files, as well as on 'configure.ac'
          touch aclocal.m4
          sleep 1
          # autoconf-generated configure depends on aclocal.m4 and on
          # configure.ac
          touch configure
          # so does autoheader-generated config.h.in
          touch config.h.in
          # and all the automake-generated Makefile.in files
          touch `find . -name Makefile.in -print`
          # finally, the makeinfo-generated '.info' files depend on the
          # corresponding '.texi' files
          touch doc/*.info

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

27.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, even
suggesting how to obtain such a tool (at least in case it is a
well-known one, like ‘makeinfo’ or ‘bison’).  This is more helpful and
user-friendly than just having the rebuild rules spewing out a terse
error message like ‘sh: TOOL: command not found’.  Similarly, ‘missing’
will warn the user if it detects that a maintainer tool it attempted to
use seems too old (be warned that diagnosing this correctly is typically
more difficult that detecting missing tools, and requires cooperation
from the tool itself, so it won’t always work).

   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 missing or too old
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 Franç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 Franç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

27.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 expanding
‘$(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: Errors with distclean,  Prev: Wildcards,  Up: FAQ

27.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: Errors with distclean,  Next: Flag Variables Ordering,  Prev: Limitations on File Names,  Up: FAQ

27.5 Errors with 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: Errors with distclean,  Up: FAQ

27.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’, ‘OBJCXXFLAGS’, ‘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 of 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.

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

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

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

27.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 (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

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

27.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 (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 use
     of silent rules (*note Automake Silent Rules::), 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 (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 (make)Remaking
     Makefiles::).
   • ‘make SHELL="/bin/bash -vx"’ can help debug complex rules.  *Note
     (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

27.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 ‘test-suite.log’ file.


File: automake.info,  Node: Copying This Manual,  Next: Indices,  Prev: FAQ,  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 © 2000-2014 Free Software Foundation, Inc.
     <http://fsf.org/>

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

  0. PREAMBLE

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

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

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

  1. APPLICABILITY AND DEFINITIONS

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

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

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

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

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

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

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

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

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

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

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

  2. VERBATIM COPYING

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

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

  3. COPYING IN QUANTITY

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

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

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

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

  4. MODIFICATIONS

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

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

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

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

       D. Preserve all the copyright notices of the Document.

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

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

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

       H. Include an unaltered copy of this License.

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

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

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

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

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

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

       O. Preserve any Warranty Disclaimers.

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

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

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

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

  5. COMBINING DOCUMENTS

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

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

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

  6. COLLECTIONS OF DOCUMENTS

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

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

  7. AGGREGATION WITH INDEPENDENT WORKS

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

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

  8. TRANSLATION

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

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

  9. TERMINATION

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

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

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

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

  10. FUTURE REVISIONS OF THIS LICENSE

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

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

  11. RELICENSING

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

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

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

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

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

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

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

       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.3
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
       Texts.  A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

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

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

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

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


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:                     Optional.            (line  19)
* AC_CONFIG_AUX_DIR <1>:                 Subpackages.         (line   6)
* AC_CONFIG_FILES:                       Requirements.        (line  15)
* AC_CONFIG_HEADERS:                     Optional.            (line  44)
* AC_CONFIG_LIBOBJ_DIR:                  Optional.            (line  40)
* AC_CONFIG_LIBOBJ_DIR <1>:              LIBOBJS.             (line  51)
* AC_CONFIG_LINKS:                       Optional.            (line  55)
* AC_CONFIG_SUBDIRS:                     Subpackages.         (line   6)
* AC_DEFUN:                              Extending aclocal.   (line  36)
* AC_F77_LIBRARY_LDFLAGS:                Optional.            (line 101)
* AC_FC_SRCEXT:                          Optional.            (line 107)
* AC_INIT:                               Public Macros.       (line  15)
* AC_LIBOBJ:                             Optional.            (line  65)
* AC_LIBOBJ <1>:                         LTLIBOBJS.           (line   6)
* AC_LIBOBJ <2>:                         LIBOBJS.             (line  11)
* AC_LIBSOURCE:                          Optional.            (line  66)
* AC_LIBSOURCE <1>:                      LIBOBJS.             (line  17)
* AC_LIBSOURCES:                         Optional.            (line  67)
* AC_OUTPUT:                             Requirements.        (line  15)
* AC_PREREQ:                             Extending aclocal.   (line  36)
* AC_PROG_CXX:                           Optional.            (line  85)
* AC_PROG_F77:                           Optional.            (line  97)
* AC_PROG_FC:                            Optional.            (line 112)
* AC_PROG_LEX:                           Public Macros.       (line  95)
* AC_PROG_LEX <1>:                       Optional.            (line 127)
* AC_PROG_LIBTOOL:                       Optional.            (line 117)
* AC_PROG_OBJC:                          Optional.            (line  89)
* AC_PROG_OBJCXX:                        Optional.            (line  93)
* AC_PROG_RANLIB:                        Optional.            (line  81)
* AC_PROG_YACC:                          Optional.            (line 121)
* AC_REQUIRE_AUX_FILE:                   Optional.            (line 131)
* AC_SUBST:                              Optional.            (line 139)
* AM_CONDITIONAL:                        Optional.            (line 152)
* AM_CONDITIONAL <1>:                    Usage of Conditionals.
                                                              (line   6)
* AM_CONDITIONAL <2>:                    Usage of Conditionals.
                                                              (line   9)
* AM_COND_IF:                            Optional.            (line 155)
* AM_COND_IF <1>:                        Usage of Conditionals.
                                                              (line  66)
* AM_COND_IF <2>:                        Usage of Conditionals.
                                                              (line  70)
* AM_DEP_TRACK:                          Private Macros.      (line  14)
* AM_GNU_GETTEXT:                        Optional.            (line 161)
* AM_GNU_GETTEXT_INTL_SUBDIR:            Optional.            (line 167)
* AM_INIT_AUTOMAKE:                      Requirements.        (line   6)
* AM_INIT_AUTOMAKE <1>:                  Public Macros.       (line   7)
* AM_MAINTAINER_MODE:                    Rebuilding.          (line   9)
* AM_MAINTAINER_MODE <1>:                maintainer-mode.     (line  37)
* AM_MAINTAINER_MODE([DEFAULT-MODE]):    Optional.            (line 172)
* AM_MAKE_INCLUDE:                       Private Macros.      (line  20)
* AM_MISSING_PROG:                       Public Macros.       (line 111)
* AM_OUTPUT_DEPENDENCY_COMMANDS:         Private Macros.      (line  15)
* AM_PATH_LISPDIR:                       Public Macros.       (line  61)
* AM_PATH_PYTHON:                        Python.              (line  28)
* AM_PROG_AR:                            Public Macros.       (line  76)
* AM_PROG_AS:                            Public Macros.       (line  83)
* AM_PROG_CC_C_O:                        Public Macros.       (line  88)
* AM_PROG_GCJ:                           Public Macros.       (line 100)
* AM_PROG_INSTALL_STRIP:                 Private Macros.      (line  25)
* AM_PROG_LEX:                           Public Macros.       (line  95)
* AM_PROG_MKDIR_P:                       Obsolete Macros.     (line  14)
* AM_PROG_UPC:                           Public Macros.       (line 105)
* AM_PROG_VALAC:                         Vala Support.        (line  20)
* AM_SANITY_CHECK:                       Private Macros.      (line  30)
* AM_SET_DEPDIR:                         Private Macros.      (line  13)
* AM_SILENT_RULES:                       Public Macros.       (line 119)
* AM_SUBST_NOTMAKE(VAR):                 Optional.            (line 180)
* AM_WITH_DMALLOC:                       Public Macros.       (line 123)
* m4_include:                            Basics of Distribution.
                                                              (line  17)
* m4_include <1>:                        Optional.            (line 190)


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:                          Parallel Test Harness.
                                                              (line  51)
* _LOG_COMPILER:                         Parallel Test Harness.
                                                              (line  51)
* _LOG_DRIVER:                           Declaring Custom Test Drivers.
                                                              (line   6)
* _LOG_DRIVER_FLAGS:                     Declaring Custom Test Drivers.
                                                              (line   6)
* _LOG_FLAGS:                            Parallel Test Harness.
                                                              (line  51)
* _LTLIBRARIES:                          Libtool Libraries.   (line   6)
* _MANS:                                 Man Pages.           (line   6)
* _PROGRAMS:                             Uniform.             (line  11)
* _PROGRAMS <1>:                         Program Sources.     (line   6)
* _PYTHON:                               Python.              (line   6)
* _SCRIPTS:                              Scripts.             (line   6)
* _SOURCES:                              Program Sources.     (line  32)
* _SOURCES <1>:                          Program Sources.     (line  33)
* _SOURCES <2>:                          Default _SOURCES.    (line   6)
* _TEXINFOS:                             Texinfo.             (line   6)
* _TEXINFOS <1>:                         Texinfo.             (line  65)
* ALLOCA:                                LTLIBOBJS.           (line   6)
* ALLOCA <1>:                            LIBOBJS.             (line   6)
* AM_CCASFLAGS:                          Assembly Support.    (line  10)
* AM_CFLAGS:                             Program Variables.   (line  50)
* AM_COLOR_TESTS:                        Scripts-based Testsuites.
                                                              (line  67)
* AM_CPPFLAGS:                           Program Variables.   (line  16)
* AM_CPPFLAGS <1>:                       Assembly Support.    (line  10)
* AM_CXXFLAGS:                           C++ Support.         (line  22)
* AM_DEFAULT_SOURCE_EXT:                 Default _SOURCES.    (line   6)
* ‘AM_DEFAULT_V’:                        Automake Silent Rules.
                                                              (line 120)
* ‘AM_DEFAULT_VERBOSITY’:                Automake Silent Rules.
                                                              (line 120)
* AM_DISTCHECK_CONFIGURE_FLAGS:          Checking the Distribution.
                                                              (line  28)
* AM_ETAGSFLAGS:                         Tags.                (line  25)
* AM_EXT_LOG_DRIVER_FLAGS:               Declaring Custom Test Drivers.
                                                              (line   6)
* AM_EXT_LOG_FLAGS:                      Parallel Test Harness.
                                                              (line  51)
* 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:    List of Automake options.
                                                              (line 135)
* AM_JAVACFLAGS:                         Java.                (line  44)
* AM_LDFLAGS:                            Linking.             (line  10)
* AM_LDFLAGS <1>:                        Program Variables.   (line  59)
* AM_LFLAGS:                             Yacc and Lex.        (line  60)
* AM_LIBTOOLFLAGS:                       Libtool Flags.       (line   6)
* AM_LOG_DRIVER_FLAGS:                   Declaring Custom Test Drivers.
                                                              (line   6)
* AM_LOG_FLAGS:                          Parallel Test Harness.
                                                              (line  51)
* AM_MAKEFLAGS:                          Subdirectories.      (line  29)
* AM_MAKEINFOFLAGS:                      Texinfo.             (line 115)
* AM_MAKEINFOHTMLFLAGS:                  Texinfo.             (line 116)
* AM_OBJCFLAGS:                          Objective C Support. (line  22)
* AM_OBJCXXFLAGS:                        Objective C++ Support.
                                                              (line  22)
* AM_RFLAGS:                             Fortran 77 Support.  (line  28)
* AM_RUNTESTFLAGS:                       DejaGnu Tests.       (line  24)
* AM_TESTS_ENVIRONMENT:                  Scripts-based Testsuites.
                                                              (line  86)
* AM_TESTS_FD_REDIRECT:                  Scripts-based Testsuites.
                                                              (line  94)
* AM_UPCFLAGS:                           Unified Parallel C Support.
                                                              (line  21)
* AM_UPDATE_INFO_DIR:                    Texinfo.             (line  92)
* ‘AM_V’:                                Automake Silent Rules.
                                                              (line 120)
* AM_VALAFLAGS:                          Vala Support.        (line  41)
* ‘AM_V_at’:                             Automake Silent Rules.
                                                              (line 120)
* ‘AM_V_GEN’:                            Automake Silent Rules.
                                                              (line 120)
* AM_YFLAGS:                             Yacc and Lex.        (line  37)
* AR:                                    Public Macros.       (line  76)
* AUTOCONF:                              automake Invocation. (line  28)
* AUTOM4TE:                              aclocal Invocation.  (line  44)
* AUTOMAKE_JOBS:                         automake Invocation. (line 174)
* AUTOMAKE_OPTIONS:                      Public Macros.       (line  10)
* AUTOMAKE_OPTIONS <1>:                  Dependencies.        (line  34)
* AUTOMAKE_OPTIONS <2>:                  List of Automake options.
                                                              (line   6)
* 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  13)
* CC:                                    Program Variables.   (line  12)
* CCAS:                                  Public Macros.       (line  83)
* CCAS <1>:                              Assembly Support.    (line  10)
* CCASFLAGS:                             Public Macros.       (line  83)
* CCASFLAGS <1>:                         Assembly Support.    (line  10)
* CFLAGS:                                Program Variables.   (line  12)
* check_:                                Uniform.             (line  95)
* check_LTLIBRARIES:                     Libtool Convenience Libraries.
                                                              (line   6)
* check_PROGRAMS:                        Program Sources.     (line   6)
* check_PROGRAMS <1>:                    Default _SOURCES.    (line  28)
* check_SCRIPTS:                         Scripts.             (line  18)
* CLASSPATH_ENV:                         Java.                (line  53)
* CLEANFILES:                            Clean.               (line  13)
* COMPILE:                               Program Variables.   (line  55)
* CONFIGURE_DEPENDENCIES:                Rebuilding.          (line  12)
* CONFIG_STATUS_DEPENDENCIES:            Rebuilding.          (line  12)
* CPPFLAGS:                              Program Variables.   (line  12)
* CPPFLAGS <1>:                          Assembly Support.    (line  10)
* CXX:                                   C++ Support.         (line  16)
* CXXCOMPILE:                            C++ Support.         (line  25)
* CXXFLAGS:                              C++ Support.         (line  19)
* CXXLINK:                               C++ Support.         (line  29)
* CXXLINK <1>:                           How the Linker is Chosen.
                                                              (line  12)
* DATA:                                  Uniform.             (line 101)
* DATA <1>:                              Data.                (line   7)
* data_DATA:                             Data.                (line   9)
* DEFS:                                  Program Variables.   (line  12)
* DEJATOOL:                              DejaGnu Tests.       (line  19)
* DESTDIR:                               DESTDIR.             (line   6)
* DESTDIR <1>:                           Staged Installs.     (line   6)
* DISABLE_HARD_ERRORS:                   Scripts-based Testsuites.
                                                              (line  32)
* DISTCHECK_CONFIGURE_FLAGS:             Checking the Distribution.
                                                              (line  28)
* distcleancheck_listfiles:              Checking the Distribution.
                                                              (line  70)
* distcleancheck_listfiles <1>:          Errors with distclean.
                                                              (line 112)
* DISTCLEANFILES:                        Clean.               (line  13)
* DISTCLEANFILES <1>:                    Checking the Distribution.
                                                              (line  70)
* distdir:                               The dist Hook.       (line  33)
* distdir <1>:                           Third-Party Makefiles.
                                                              (line  25)
* distuninstallcheck_listfiles:          Checking the Distribution.
                                                              (line 106)
* dist_:                                 Alternative.         (line  29)
* dist_ <1>:                             Fine-grained Distribution Control.
                                                              (line   6)
* dist_lisp_LISP:                        Emacs Lisp.          (line  11)
* dist_noinst_LISP:                      Emacs Lisp.          (line  11)
* DIST_SUBDIRS:                          Subdirectories with AM_CONDITIONAL.
                                                              (line  25)
* DIST_SUBDIRS <1>:                      Basics of Distribution.
                                                              (line  47)
* DVIPS:                                 Texinfo.             (line 141)
* EMACS:                                 Public Macros.       (line  61)
* ETAGSFLAGS:                            Tags.                (line  25)
* ETAGS_ARGS:                            Tags.                (line  25)
* EXPECT:                                DejaGnu Tests.       (line  19)
* EXTRA_DIST:                            Basics of Distribution.
                                                              (line  34)
* EXTRA_maude_DEPENDENCIES:              Linking.             (line  41)
* EXTRA_maude_DEPENDENCIES <1>:          Program and Library Variables.
                                                              (line 119)
* EXTRA_maude_SOURCES:                   Program and Library Variables.
                                                              (line  53)
* EXTRA_PROGRAMS:                        Conditional Programs.
                                                              (line  15)
* EXT_LOG_COMPILE:                       Parallel Test Harness.
                                                              (line  51)
* EXT_LOG_COMPILER:                      Parallel Test Harness.
                                                              (line  51)
* EXT_LOG_DRIVER:                        Declaring Custom Test Drivers.
                                                              (line   6)
* EXT_LOG_DRIVER_FLAGS:                  Declaring Custom Test Drivers.
                                                              (line   6)
* EXT_LOG_FLAGS:                         Parallel Test Harness.
                                                              (line  51)
* F77:                                   Fortran 77 Support.  (line  16)
* F77COMPILE:                            Fortran 77 Support.  (line  31)
* F77LINK:                               How the Linker is Chosen.
                                                              (line  13)
* FC:                                    Fortran 9x Support.  (line  16)
* FCCOMPILE:                             Fortran 9x Support.  (line  25)
* FCFLAGS:                               Fortran 9x Support.  (line  19)
* FCLINK:                                How the Linker is Chosen.
                                                              (line  14)
* FCLINK <1>:                            Fortran 9x Support.  (line  29)
* 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 100)
* GCJFLAGS:                              Public Macros.       (line 100)
* GCJFLAGS <1>:                          Java Support with gcj.
                                                              (line  16)
* GCJLINK:                               How the Linker is Chosen.
                                                              (line  10)
* GTAGS_ARGS:                            Tags.                (line  60)
* GZIP_ENV:                              Basics of Distribution.
                                                              (line  14)
* HEADERS:                               Uniform.             (line 101)
* host_triplet:                          Optional.            (line  14)
* INCLUDES:                              Program Variables.   (line  44)
* include_HEADERS:                       Headers.             (line   6)
* info_TEXINFOS:                         Texinfo.             (line   6)
* JAVA:                                  Uniform.             (line 101)
* JAVAC:                                 Java.                (line  37)
* JAVACFLAGS:                            Java.                (line  40)
* JAVAROOT:                              Java.                (line  49)
* LDADD:                                 Linking.             (line  10)
* LDFLAGS:                               Program Variables.   (line  12)
* LFLAGS:                                Yacc and Lex.        (line  60)
* libexec_PROGRAMS:                      Program Sources.     (line   6)
* libexec_SCRIPTS:                       Scripts.             (line  18)
* LIBOBJS:                               Optional.            (line  68)
* LIBOBJS <1>:                           LTLIBOBJS.           (line   6)
* LIBOBJS <2>:                           LIBOBJS.             (line   6)
* LIBRARIES:                             Uniform.             (line 101)
* LIBS:                                  Program Variables.   (line  12)
* LIBTOOLFLAGS:                          Libtool Flags.       (line   6)
* lib_LIBRARIES:                         A Library.           (line   6)
* lib_LTLIBRARIES:                       Libtool Libraries.   (line   6)
* LINK:                                  Program Variables.   (line  64)
* LINK <1>:                              How the Linker is Chosen.
                                                              (line  17)
* LISP:                                  Uniform.             (line 101)
* lispdir:                               Public Macros.       (line  61)
* lisp_LISP:                             Emacs Lisp.          (line   6)
* localstate_DATA:                       Data.                (line   9)
* LOG_COMPILE:                           Parallel Test Harness.
                                                              (line  51)
* LOG_COMPILER:                          Parallel Test Harness.
                                                              (line  51)
* LOG_DRIVER:                            Declaring Custom Test Drivers.
                                                              (line   6)
* LOG_DRIVER_FLAGS:                      Declaring Custom Test Drivers.
                                                              (line   6)
* LOG_FLAGS:                             Parallel Test Harness.
                                                              (line  51)
* LTALLOCA:                              LTLIBOBJS.           (line   6)
* LTALLOCA <1>:                          LIBOBJS.             (line   6)
* LTLIBOBJS:                             LTLIBOBJS.           (line   6)
* LTLIBOBJS <1>:                         LIBOBJS.             (line   6)
* LTLIBRARIES:                           Uniform.             (line 101)
* MAINTAINERCLEANFILES:                  Clean.               (line  13)
* MAKE:                                  Subdirectories.      (line  29)
* MAKEINFO:                              Texinfo.             (line  99)
* MAKEINFOFLAGS:                         Texinfo.             (line 109)
* MAKEINFOHTML:                          Texinfo.             (line 105)
* MANS:                                  Uniform.             (line 101)
* man_MANS:                              Man Pages.           (line   6)
* maude_AR:                              Program and Library Variables.
                                                              (line  68)
* maude_CCASFLAGS:                       Program and Library Variables.
                                                              (line 170)
* maude_CFLAGS:                          Program and Library Variables.
                                                              (line 171)
* maude_CPPFLAGS:                        Program and Library Variables.
                                                              (line 172)
* maude_CXXFLAGS:                        Program and Library Variables.
                                                              (line 173)
* maude_DEPENDENCIES:                    Linking.             (line  41)
* maude_DEPENDENCIES <1>:                Program and Library Variables.
                                                              (line 118)
* maude_FFLAGS:                          Program and Library Variables.
                                                              (line 174)
* maude_GCJFLAGS:                        Program and Library Variables.
                                                              (line 175)
* maude_LDADD:                           Linking.             (line  17)
* maude_LDADD <1>:                       Program and Library Variables.
                                                              (line  86)
* maude_LDFLAGS:                         Linking.             (line  37)
* maude_LDFLAGS <1>:                     Program and Library Variables.
                                                              (line 106)
* maude_LFLAGS:                          Program and Library Variables.
                                                              (line 176)
* maude_LIBADD:                          A Library.           (line  26)
* maude_LIBADD <1>:                      Program and Library Variables.
                                                              (line  78)
* maude_LIBTOOLFLAGS:                    Libtool Flags.       (line   6)
* maude_LIBTOOLFLAGS <1>:                Program and Library Variables.
                                                              (line 111)
* maude_LINK:                            Program and Library Variables.
                                                              (line 154)
* maude_OBJCFLAGS:                       Program and Library Variables.
                                                              (line 177)
* maude_OBJCXXFLAGS:                     Program and Library Variables.
                                                              (line 178)
* maude_RFLAGS:                          Program and Library Variables.
                                                              (line 179)
* maude_SHORTNAME:                       Program and Library Variables.
                                                              (line 210)
* maude_SOURCES:                         Program and Library Variables.
                                                              (line  18)
* maude_UPCFLAGS:                        Program and Library Variables.
                                                              (line 180)
* maude_YFLAGS:                          Program and Library Variables.
                                                              (line 181)
* MISSING:                               Public Macros.       (line 111)
* MKDIR_P:                               Obsolete Macros.     (line  14)
* mkdir_p:                               Obsolete Macros.     (line  14)
* MOSTLYCLEANFILES:                      Clean.               (line  13)
* nobase_:                               Alternative.         (line  23)
* nodist_:                               Alternative.         (line  29)
* nodist_ <1>:                           Fine-grained Distribution Control.
                                                              (line   6)
* noinst_:                               Uniform.             (line  90)
* noinst_HEADERS:                        Headers.             (line   6)
* noinst_HEADERS <1>:                    Headers.             (line  23)
* 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:                              Objective C Support. (line  29)
* OBJCLINK <1>:                          How the Linker is Chosen.
                                                              (line  15)
* OBJCXX:                                Objective C++ Support.
                                                              (line  16)
* OBJCXXCOMPILE:                         Objective C++ Support.
                                                              (line  25)
* OBJCXXFLAGS:                           Objective C++ Support.
                                                              (line  19)
* OBJCXXLINK:                            Objective C++ Support.
                                                              (line  29)
* OBJCXXLINK <1>:                        How the Linker is Chosen.
                                                              (line  11)
* oldinclude_HEADERS:                    Headers.             (line   6)
* PACKAGE:                               Basics of Distribution.
                                                              (line   6)
* pkgdatadir:                            Uniform.             (line  19)
* pkgdata_DATA:                          Data.                (line   9)
* pkgdata_SCRIPTS:                       Scripts.             (line  18)
* pkgincludedir:                         Uniform.             (line  19)
* pkginclude_HEADERS:                    Headers.             (line   6)
* pkglibdir:                             Uniform.             (line  19)
* pkglibexecdir:                         Uniform.             (line  19)
* pkglibexec_PROGRAMS:                   Program Sources.     (line   6)
* pkglibexec_SCRIPTS:                    Scripts.             (line  18)
* pkglib_LIBRARIES:                      A Library.           (line   6)
* pkglib_LTLIBRARIES:                    Libtool Libraries.   (line   6)
* pkgpyexecdir:                          Python.              (line 105)
* pkgpythondir:                          Python.              (line  91)
* PROGRAMS:                              Uniform.             (line  17)
* PROGRAMS <1>:                          Uniform.             (line 101)
* pyexecdir:                             Python.              (line  96)
* PYTHON:                                Uniform.             (line 101)
* PYTHON <1>:                            Python.              (line  56)
* pythondir:                             Python.              (line  87)
* PYTHON_EXEC_PREFIX:                    Python.              (line  77)
* PYTHON_PLATFORM:                       Python.              (line  82)
* PYTHON_PREFIX:                         Python.              (line  72)
* PYTHON_VERSION:                        Python.              (line  68)
* RECHECK_LOGS:                          Parallel Test Harness.
                                                              (line 118)
* RFLAGS:                                Fortran 77 Support.  (line  25)
* 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:                               Uniform.             (line 101)
* SCRIPTS <1>:                           Scripts.             (line   9)
* sharedstate_DATA:                      Data.                (line   9)
* SOURCES:                               Program Sources.     (line  33)
* SOURCES <1>:                           Default _SOURCES.    (line   6)
* SUBDIRS:                               Subdirectories.      (line   8)
* SUBDIRS <1>:                           Basics of Distribution.
                                                              (line  47)
* SUFFIXES:                              Suffixes.            (line   6)
* sysconf_DATA:                          Data.                (line   9)
* TAGS_DEPENDENCIES:                     Tags.                (line  35)
* target_triplet:                        Optional.            (line  14)
* TESTS:                                 Scripts-based Testsuites.
                                                              (line  86)
* TESTS <1>:                             Parallel Test Harness.
                                                              (line  12)
* TESTS_ENVIRONMENT:                     Scripts-based Testsuites.
                                                              (line  86)
* TEST_EXTENSIONS:                       Parallel Test Harness.
                                                              (line  34)
* TEST_LOGS:                             Parallel Test Harness.
                                                              (line  34)
* TEST_SUITE_LOG:                        Parallel Test Harness.
                                                              (line  12)
* TEXI2DVI:                              Texinfo.             (line 132)
* TEXI2PDF:                              Texinfo.             (line 137)
* TEXINFOS:                              Uniform.             (line 101)
* TEXINFOS <1>:                          Texinfo.             (line  65)
* TEXINFO_TEX:                           Texinfo.             (line 145)
* top_distdir:                           The dist Hook.       (line  33)
* top_distdir <1>:                       Third-Party Makefiles.
                                                              (line  25)
* UPC:                                   Public Macros.       (line 105)
* UPC <1>:                               Unified Parallel C Support.
                                                              (line  15)
* UPCCOMPILE:                            Unified Parallel C Support.
                                                              (line  24)
* UPCFLAGS:                              Unified Parallel C Support.
                                                              (line  18)
* UPCLINK:                               Unified Parallel C Support.
                                                              (line  28)
* UPCLINK <1>:                           How the Linker is Chosen.
                                                              (line  16)
* ‘V’:                                   Automake Silent Rules.
                                                              (line  88)
* VALAC:                                 Vala Support.        (line  34)
* VALAFLAGS:                             Vala Support.        (line  38)
* VERBOSE:                               Parallel Test Harness.
                                                              (line  26)
* VERSION:                               Basics of Distribution.
                                                              (line   6)
* WARNINGS:                              automake Invocation. (line 167)
* WARNINGS <1>:                          aclocal Options.     (line  91)
* WITH_DMALLOC:                          Public Macros.       (line 123)
* XFAIL_TESTS:                           Scripts-based Testsuites.
                                                              (line  32)
* XZ_OPT:                                The Types of Distributions.
                                                              (line  24)
* YACC:                                  Optional.            (line 122)
* YFLAGS:                                Yacc and Lex.        (line  37)

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

B.3 General Index
=================

 [index ]
* Menu:

* ‘##’ (special Automake comment):       General Operation.   (line  68)
* ‘#serial’ syntax:                      Serials.             (line   6)
* ‘$(LIBOBJS)’ and empty libraries:      LIBOBJS.             (line  72)
* +=:                                    General Operation.   (line  24)
* --add-missing:                         automake Invocation. (line  41)
* --automake-acdir:                      aclocal Options.     (line   9)
* --build=BUILD:                         Cross-Compilation.   (line  14)
* --copy:                                automake Invocation. (line  71)
* --diff:                                aclocal Options.     (line  18)
* --disable-dependency-tracking:         Dependency Tracking. (line  33)
* --disable-maintainer-mode:             Optional.            (line 173)
* --disable-silent-rules:                Automake Silent Rules.
                                                              (line  85)
* --dry-run:                             aclocal Options.     (line  23)
* ‘--enable-debug’, example:             Usage of Conditionals.
                                                              (line  21)
* --enable-dependency-tracking:          Dependency Tracking. (line  43)
* --enable-maintainer-mode:              Optional.            (line 173)
* --enable-silent-rules:                 Automake Silent Rules.
                                                              (line  85)
* --force:                               aclocal Options.     (line  45)
* --force-missing:                       automake Invocation. (line  76)
* --foreign:                             automake Invocation. (line  82)
* --gnits:                               automake Invocation. (line  86)
* ‘--gnits’, complete description:       Gnits.               (line  29)
* --gnu:                                 automake Invocation. (line  90)
* ‘--gnu’, complete description:         Gnits.               (line   6)
* ‘--gnu’, required files:               Gnits.               (line   6)
* --help:                                automake Invocation. (line  94)
* --help <1>:                            aclocal Options.     (line  27)
* ‘--help’ check:                        List of Automake options.
                                                              (line 129)
* --help=recursive:                      Nested Packages.     (line  30)
* --host=HOST:                           Cross-Compilation.   (line  16)
* --include-deps:                        automake Invocation. (line 102)
* --install:                             aclocal Options.     (line  34)
* --libdir:                              automake Invocation. (line  61)
* --no-force:                            automake Invocation. (line 107)
* --output:                              aclocal Options.     (line  55)
* --output-dir:                          automake Invocation. (line 114)
* --prefix:                              Standard Directory Variables.
                                                              (line  33)
* --print-ac-dir:                        aclocal Options.     (line  58)
* --print-libdir:                        automake Invocation. (line  65)
* --program-prefix=PREFIX:               Renaming.            (line  16)
* --program-suffix=SUFFIX:               Renaming.            (line  18)
* --program-transform-name=PROGRAM:      Renaming.            (line  20)
* --system-acdir:                        aclocal Options.     (line  13)
* --target=TARGET:                       Cross-Compilation.   (line  55)
* --verbose:                             automake Invocation. (line 121)
* --verbose <1>:                         aclocal Options.     (line  69)
* --version:                             automake Invocation. (line 125)
* --version <1>:                         aclocal Options.     (line  72)
* ‘--version’ check:                     List of Automake options.
                                                              (line 129)
* --warnings:                            automake Invocation. (line 129)
* --warnings <1>:                        aclocal Options.     (line  76)
* --with-dmalloc:                        Public Macros.       (line 123)
* -a:                                    automake Invocation. (line  41)
* -c:                                    automake Invocation. (line  70)
* -f:                                    automake Invocation. (line  75)
* ‘-hook’ targets:                       Extending.           (line  66)
* -i:                                    automake Invocation. (line  98)
* -I:                                    aclocal Options.     (line  30)
* ‘-l’ and ‘LDADD’:                      Linking.             (line  70)
* ‘-local’ targets:                      Extending.           (line  37)
* ‘-module’, libtool:                    Libtool Modules.     (line   6)
* -o:                                    automake Invocation. (line 114)
* -v:                                    automake Invocation. (line 121)
* -W:                                    automake Invocation. (line 129)
* -W <1>:                                aclocal Options.     (line  76)
* -Wall:                                 amhello's configure.ac Setup Explained.
                                                              (line  38)
* -Werror:                               amhello's configure.ac Setup Explained.
                                                              (line  38)
* ‘.la’ suffix, defined:                 Libtool Concept.     (line   6)
* ‘.log’ files:                          Parallel Test Harness.
                                                              (line  12)
* ‘.trs’ files:                          Parallel Test Harness.
                                                              (line  12)
* :copy-in-global-log::                  Log files generation and test results recording.
                                                              (line  44)
* :recheck::                             Log files generation and test results recording.
                                                              (line  38)
* :test-global-result::                  Log files generation and test results recording.
                                                              (line  54)
* ‘:test-result:’:                       Log files generation and test results recording.
                                                              (line  24)
* ‘_DATA’ primary, defined:              Data.                (line   6)
* ‘_DEPENDENCIES’, defined:              Linking.             (line  41)
* ‘_HEADERS’ primary, defined:           Headers.             (line   6)
* ‘_JAVA’ primary, defined:              Java.                (line   6)
* ‘_LDFLAGS’, defined:                   Linking.             (line  37)
* ‘_LDFLAGS’, libtool:                   Libtool Flags.       (line   6)
* ‘_LIBADD’, libtool:                    Libtool Flags.       (line   6)
* ‘_LIBRARIES’ primary, defined:         A Library.           (line   6)
* ‘_LIBTOOLFLAGS’, libtool:              Libtool Flags.       (line   6)
* ‘_LISP’ primary, defined:              Emacs Lisp.          (line   6)
* ‘_LTLIBRARIES’ primary, defined:       Libtool Libraries.   (line   6)
* ‘_MANS’ primary, defined:              Man Pages.           (line   6)
* ‘_PROGRAMS’ primary variable:          Uniform.             (line  11)
* ‘_PYTHON’ primary, defined:            Python.              (line   6)
* ‘_SCRIPTS’ primary, defined:           Scripts.             (line   6)
* ‘_SOURCES’ and header files:           Program Sources.     (line  39)
* ‘_SOURCES’ primary, defined:           Program Sources.     (line  32)
* ‘_SOURCES’, default:                   Default _SOURCES.    (line   6)
* ‘_SOURCES’, empty:                     Default _SOURCES.    (line  44)
* ‘_TEXINFOS’ primary, defined:          Texinfo.             (line   6)
* ‘acinclude.m4’, defined:               Complete.            (line  23)
* ‘aclocal’ and serial numbers:          Serials.             (line   6)
* ‘aclocal’ program, introduction:       Complete.            (line  23)
* ‘aclocal’ search path:                 Macro Search Path.   (line   6)
* ‘aclocal’’s scheduled death:           Future of aclocal.   (line   6)
* ‘aclocal’, extending:                  Extending aclocal.   (line   6)
* ‘aclocal’, Invocation:                 aclocal Invocation.  (line   6)
* ‘aclocal’, Invoking:                   aclocal Invocation.  (line   6)
* ‘aclocal’, Options:                    aclocal Options.     (line   6)
* ‘aclocal’, using:                      configure.           (line   6)
* ‘aclocal.m4’, preexisting:             Complete.            (line  23)
* ‘ACLOCAL_PATH’:                        Macro Search Path.   (line 116)
* ‘AC_CONFIG_FILES’, conditional:        Usage of Conditionals.
                                                              (line  79)
* ‘AC_SUBST’ and ‘SUBDIRS’:              Subdirectories with AC_SUBST.
                                                              (line   6)
* Adding new ‘SUFFIXES’:                 Suffixes.            (line   6)
* all:                                   Standard Targets.    (line  16)
* all <1>:                               Extending.           (line  41)
* all-local:                             Extending.           (line  41)
* ‘ALLOCA’, and Libtool:                 LTLIBOBJS.           (line   6)
* ‘ALLOCA’, example:                     LIBOBJS.             (line   6)
* ‘ALLOCA’, special handling:            LIBOBJS.             (line   6)
* ‘amhello-1.0.tar.gz’, creation:        Hello World.         (line   6)
* ‘amhello-1.0.tar.gz’, location:        Use Cases.           (line   6)
* ‘amhello-1.0.tar.gz’, use cases:       Use Cases.           (line   6)
* ‘AM_CCASFLAGS’ and ‘CCASFLAGS’:        Flag Variables Ordering.
                                                              (line  20)
* ‘AM_CFLAGS’ and ‘CFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* ‘AM_CONDITIONAL’ and ‘SUBDIRS’:        Subdirectories with AM_CONDITIONAL.
                                                              (line   6)
* ‘AM_CPPFLAGS’ and ‘CPPFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* ‘AM_CXXFLAGS’ and ‘CXXFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* ‘AM_FCFLAGS’ and ‘FCFLAGS’:            Flag Variables Ordering.
                                                              (line  20)
* ‘AM_FFLAGS’ and ‘FFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* ‘AM_GCJFLAGS’ and ‘GCJFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* ‘AM_INIT_AUTOMAKE’, example use:       Complete.            (line  11)
* ‘AM_LDFLAGS’ and ‘LDFLAGS’:            Flag Variables Ordering.
                                                              (line  20)
* ‘AM_LFLAGS’ and ‘LFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* ‘AM_LIBTOOLFLAGS’ and ‘LIBTOOLFLAGS’:  Flag Variables Ordering.
                                                              (line  20)
* ‘AM_MAINTAINER_MODE’, purpose:         maintainer-mode.     (line  37)
* ‘AM_OBJCFLAGS’ and ‘OBJCFLAGS’:        Flag Variables Ordering.
                                                              (line  20)
* ‘AM_OBJCXXFLAGS’ and ‘OBJXXCFLAGS’:    Flag Variables Ordering.
                                                              (line  20)
* ‘AM_RFLAGS’ and ‘RFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* ‘AM_UPCFLAGS’ and ‘UPCFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* ‘AM_YFLAGS’ and ‘YFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* Append operator:                       General Operation.   (line  24)
* ARG_MAX:                               Length Limitations.  (line   6)
* ‘autogen.sh’ and ‘autoreconf’:         Error required file ltmain.sh not found.
                                                              (line   6)
* autom4te:                              aclocal Invocation.  (line  44)
* Automake constraints:                  Introduction.        (line  21)
* ‘automake’ options:                    automake Invocation. (line  37)
* Automake parser, limitations of:       General Operation.   (line  33)
* Automake requirements:                 Introduction.        (line  26)
* Automake requirements <1>:             Requirements.        (line   6)
* ‘automake’, invocation:                automake Invocation. (line   6)
* ‘automake’, invoking:                  automake Invocation. (line   6)
* Automake, recursive operation:         General Operation.   (line  58)
* Automatic dependency tracking:         Dependencies.        (line  11)
* Automatic linker selection:            How the Linker is Chosen.
                                                              (line   6)
* ‘autoreconf’ and ‘libtoolize’:         Error required file ltmain.sh not found.
                                                              (line   6)
* ‘autoreconf’, example:                 Creating amhello.    (line  59)
* ‘autoscan’:                            amhello's configure.ac Setup Explained.
                                                              (line  89)
* Autotools, introduction:               GNU Build System.    (line  43)
* Autotools, purpose:                    Why Autotools.       (line   6)
* autoupdate:                            Obsolete Macros.     (line   6)
* Auxiliary programs:                    Auxiliary Programs.  (line   6)
* Avoiding man page renaming:            Man Pages.           (line  54)
* Avoiding path stripping:               Alternative.         (line  23)
* Binary package:                        DESTDIR.             (line  22)
* ‘bootstrap.sh’ and ‘autoreconf’:       Error required file ltmain.sh not found.
                                                              (line   6)
* Bugs, reporting:                       Introduction.        (line  30)
* build tree and source tree:            VPATH Builds.        (line   6)
* ‘BUILT_SOURCES’, defined:              Sources.             (line  27)
* C++ support:                           C++ Support.         (line   6)
* canonicalizing Automake variables:     Canonicalization.    (line   6)
* ‘CCASFLAGS’ and ‘AM_CCASFLAGS’:        Flag Variables Ordering.
                                                              (line  20)
* ‘CFLAGS’ and ‘AM_CFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* cfortran:                              Mixing Fortran 77 With C and C++.
                                                              (line   6)
* check:                                 Standard Targets.    (line  31)
* check <1>:                             Tests.               (line   6)
* check <2>:                             Extending.           (line  41)
* check-local:                           Extending.           (line  41)
* check-news:                            List of Automake options.
                                                              (line  14)
* ‘check_’ primary prefix, definition:   Uniform.             (line  95)
* ‘check_PROGRAMS’ example:              Default _SOURCES.    (line  28)
* clean:                                 Standard Targets.    (line  27)
* clean <1>:                             Extending.           (line  41)
* clean-local:                           Clean.               (line  15)
* clean-local <1>:                       Extending.           (line  41)
* Colorized testsuite output:            Scripts-based Testsuites.
                                                              (line  67)
* command line length limit:             Length Limitations.  (line   6)
* Comment, special to Automake:          General Operation.   (line  68)
* Compilation of Java to bytecode:       Java.                (line   6)
* Compilation of Java to native code:    Java Support with gcj.
                                                              (line   6)
* Compile Flag Variables:                Flag Variables Ordering.
                                                              (line  20)
* Complete example:                      Complete.            (line   6)
* Conditional example, ‘--enable-debug’: Usage of Conditionals.
                                                              (line  21)
* conditional libtool libraries:         Conditional Libtool Libraries.
                                                              (line   6)
* Conditional programs:                  Conditional Programs.
                                                              (line   6)
* Conditional subdirectories:            Conditional Subdirectories.
                                                              (line   6)
* Conditional ‘SUBDIRS’:                 Conditional Subdirectories.
                                                              (line   6)
* Conditionals:                          Conditionals.        (line   6)
* ‘config.guess’:                        automake Invocation. (line  39)
* ‘config.site’ example:                 config.site.         (line   6)
* configuration variables, overriding:   Standard Configuration Variables.
                                                              (line   6)
* Configuration, basics:                 Basic Installation.  (line   6)
* Configure substitutions in ‘TESTS’:    Parallel Test Harness.
                                                              (line  46)
* ‘configure.ac’, Hello World:           amhello's configure.ac Setup Explained.
                                                              (line   6)
* ‘configure.ac’, scanning:              configure.           (line   6)
* conflicting definitions:               Extending.           (line  14)
* Constraints of Automake:               Introduction.        (line  21)
* convenience libraries, libtool:        Libtool Convenience Libraries.
                                                              (line   6)
* copying semantics:                     Extending.           (line  10)
* ‘cpio’ example:                        Uniform.             (line  36)
* ‘CPPFLAGS’ and ‘AM_CPPFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* cross-compilation:                     Cross-Compilation.   (line   6)
* cross-compilation example:             Cross-Compilation.   (line  25)
* CVS and generated files:               CVS.                 (line  49)
* CVS and third-party files:             CVS.                 (line 167)
* CVS and timestamps:                    CVS.                 (line  28)
* ‘CXXFLAGS’ and ‘AM_CXXFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* ‘DATA’ primary, defined:               Data.                (line   6)
* debug build, example:                  VPATH Builds.        (line  46)
* debugging rules:                       Debugging Make Rules.
                                                              (line   6)
* default source, Libtool modules example: Default _SOURCES.  (line  38)
* default verbosity for silent rules:    Automake Silent Rules.
                                                              (line  92)
* default ‘_SOURCES’:                    Default _SOURCES.    (line   6)
* definitions, conflicts:                Extending.           (line  14)
* dejagnu:                               DejaGnu Tests.       (line  19)
* dejagnu <1>:                           List of Automake options.
                                                              (line  18)
* ‘depcomp’:                             Dependencies.        (line  22)
* dependencies and distributed files:    Errors with distclean.
                                                              (line   6)
* Dependency tracking:                   Dependency Tracking. (line   6)
* Dependency tracking <1>:               Dependencies.        (line  11)
* Dependency tracking, disabling:        Dependencies.        (line  36)
* directory variables:                   Standard Directory Variables.
                                                              (line   6)
* ‘dirlist’:                             Macro Search Path.   (line  52)
* Disabling dependency tracking:         Dependencies.        (line  37)
* Disabling hard errors:                 Scripts-based Testsuites.
                                                              (line  32)
* dist:                                  Standard Targets.    (line  35)
* dist <1>:                              Basics of Distribution.
                                                              (line   6)
* dist-bzip2:                            The Types of Distributions.
                                                              (line  18)
* dist-bzip2 <1>:                        List of Automake options.
                                                              (line  22)
* dist-bzip2 <2>:                        List of Automake options.
                                                              (line  22)
* dist-gzip:                             The Types of Distributions.
                                                              (line  11)
* dist-hook:                             The dist Hook.       (line   6)
* dist-hook <1>:                         Extending.           (line  66)
* dist-lzip:                             The Types of Distributions.
                                                              (line  22)
* dist-lzip <1>:                         List of Automake options.
                                                              (line  25)
* dist-lzip <2>:                         List of Automake options.
                                                              (line  25)
* dist-shar:                             The Types of Distributions.
                                                              (line  45)
* dist-shar <1>:                         List of Automake options.
                                                              (line  36)
* dist-shar <2>:                         List of Automake options.
                                                              (line  34)
* dist-tarZ:                             The Types of Distributions.
                                                              (line  39)
* dist-tarZ <1>:                         List of Automake options.
                                                              (line  41)
* dist-tarZ <2>:                         List of Automake options.
                                                              (line  39)
* dist-xz:                               The Types of Distributions.
                                                              (line  30)
* dist-xz <1>:                           List of Automake options.
                                                              (line  28)
* dist-xz <2>:                           List of Automake options.
                                                              (line  28)
* dist-zip:                              The Types of Distributions.
                                                              (line  33)
* dist-zip <1>:                          List of Automake options.
                                                              (line  31)
* dist-zip <2>:                          List of Automake options.
                                                              (line  31)
* distcheck:                             Creating amhello.    (line 100)
* distcheck <1>:                         Checking the Distribution.
                                                              (line   6)
* ‘distcheck’ better than ‘dist’:        Preparing Distributions.
                                                              (line  10)
* ‘distcheck’ example:                   Creating amhello.    (line 100)
* distcheck-hook:                        Checking the Distribution.
                                                              (line  55)
* distclean:                             Standard Targets.    (line  29)
* distclean <1>:                         Extending.           (line  41)
* distclean <2>:                         Errors with distclean.
                                                              (line   6)
* ‘distclean’, diagnostic:               Errors with distclean.
                                                              (line   6)
* distclean-local:                       Clean.               (line  15)
* distclean-local <1>:                   Extending.           (line  41)
* distcleancheck:                        Checking the Distribution.
                                                              (line  70)
* distdir:                               Third-Party Makefiles.
                                                              (line  25)
* Distinction between errors and failures in testsuites: Generalities about Testing.
                                                              (line  48)
* Distributions, preparation:            Preparing Distributions.
                                                              (line   6)
* distuninstallcheck:                    Checking the Distribution.
                                                              (line 106)
* ‘dist_’ and ‘nobase_’:                 Alternative.         (line  29)
* ‘dist_’ and ‘notrans_’:                Man Pages.           (line  63)
* ‘DIST_SUBDIRS’, explained:             SUBDIRS vs DIST_SUBDIRS.
                                                              (line   6)
* ‘dmalloc’, support for:                Public Macros.       (line 123)
* dvi:                                   Texinfo.             (line  25)
* dvi <1>:                               Extending.           (line  41)
* DVI output using Texinfo:              Texinfo.             (line   6)
* dvi-local:                             Extending.           (line  41)
* E-mail, bug reports:                   Introduction.        (line  30)
* ‘EDITION’ Texinfo flag:                Texinfo.             (line  35)
* else:                                  Usage of Conditionals.
                                                              (line  36)
* Empty libraries:                       A Library.           (line  48)
* Empty libraries and ‘$(LIBOBJS)’:      LIBOBJS.             (line  72)
* empty ‘_SOURCES’:                      Default _SOURCES.    (line  44)
* endif:                                 Usage of Conditionals.
                                                              (line  36)
* Example conditional ‘--enable-debug’:  Usage of Conditionals.
                                                              (line  21)
* Example conditional ‘AC_CONFIG_FILES’: Usage of Conditionals.
                                                              (line  79)
* Example Hello World:                   Hello World.         (line   6)
* Example of recursive operation:        General Operation.   (line  58)
* Example of shared libraries:           Libtool Libraries.   (line   6)
* Example, ‘EXTRA_PROGRAMS’:             Uniform.             (line  36)
* Example, ‘false’ and ‘true’:           true.                (line   6)
* Example, mixed language:               Mixing Fortran 77 With C and C++.
                                                              (line  34)
* Executable extension:                  EXEEXT.              (line   6)
* Exit status 77, special interpretation: Scripts-based Testsuites.
                                                              (line  27)
* Exit status 99, special interpretation: Scripts-based Testsuites.
                                                              (line  27)
* expected failure:                      Generalities about Testing.
                                                              (line  39)
* expected test failure:                 Generalities about Testing.
                                                              (line  39)
* Expected test failure:                 Scripts-based Testsuites.
                                                              (line  32)
* Extending ‘aclocal’:                   Extending aclocal.   (line   6)
* Extending list of installation directories: Uniform.        (line  56)
* Extension, executable:                 EXEEXT.              (line   6)
* Extra files distributed with Automake: automake Invocation. (line  39)
* ‘EXTRA_’, prepending:                  Uniform.             (line  29)
* ‘EXTRA_PROGRAMS’, defined:             Uniform.             (line  36)
* ‘EXTRA_PROGRAMS’, defined <1>:         Conditional Programs.
                                                              (line  15)
* ‘EXTRA_prog_SOURCES’, defined:         Conditional Sources. (line  18)
* ‘false’ Example:                       true.                (line   6)
* ‘FCFLAGS’ and ‘AM_FCFLAGS’:            Flag Variables Ordering.
                                                              (line  20)
* Features of the GNU Build System:      Use Cases.           (line   6)
* ‘FFLAGS’ and ‘AM_FFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* file names, limitations on:            Limitations on File Names.
                                                              (line   6)
* filename-length-max=99:                List of Automake options.
                                                              (line  44)
* Files distributed with Automake:       automake Invocation. (line  39)
* First line of Makefile.am:             General Operation.   (line  74)
* Flag variables, ordering:              Flag Variables Ordering.
                                                              (line   6)
* Flag Variables, Ordering:              Flag Variables Ordering.
                                                              (line  20)
* ‘FLIBS’, defined:                      Mixing Fortran 77 With C and C++.
                                                              (line  21)
* foreign:                               amhello's configure.ac Setup Explained.
                                                              (line  38)
* foreign <1>:                           List of Automake options.
                                                              (line   9)
* ‘foreign’ strictness:                  Strictness.          (line  10)
* Fortran 77 support:                    Fortran 77 Support.  (line   6)
* Fortran 77, mixing with C and C++:     Mixing Fortran 77 With C and C++.
                                                              (line   6)
* Fortran 77, Preprocessing:             Preprocessing Fortran 77.
                                                              (line   6)
* Fortran 9x support:                    Fortran 9x Support.  (line   6)
* ‘GCJFLAGS’ and ‘AM_GCJFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* generated files and CVS:               CVS.                 (line  49)
* generated files, distributed:          CVS.                 (line   9)
* Gettext support:                       gettext.             (line   6)
* git-dist:                              General Operation.   (line  12)
* ‘git-dist’, non-standard example:      General Operation.   (line  12)
* gnits:                                 List of Automake options.
                                                              (line   9)
* ‘gnits’ strictness:                    Strictness.          (line  10)
* gnu:                                   List of Automake options.
                                                              (line   9)
* GNU Build System, basics:              Basic Installation.  (line   6)
* GNU Build System, features:            Use Cases.           (line   6)
* GNU Build System, introduction:        GNU Build System.    (line   6)
* GNU Build System, use cases:           Use Cases.           (line   6)
* GNU Coding Standards:                  GNU Build System.    (line  29)
* GNU Gettext support:                   gettext.             (line   6)
* GNU make extensions:                   General Operation.   (line  20)
* GNU Makefile standards:                Introduction.        (line  12)
* ‘gnu’ strictness:                      Strictness.          (line  10)
* ‘GNUmakefile’ including ‘Makefile’:    Third-Party Makefiles.
                                                              (line 111)
* hard error:                            Generalities about Testing.
                                                              (line  48)
* Header files in ‘_SOURCES’:            Program Sources.     (line  39)
* ‘HEADERS’ primary, defined:            Headers.             (line   6)
* ‘HEADERS’, installation directories:   Headers.             (line   6)
* Hello World example:                   Hello World.         (line   6)
* hook targets:                          Extending.           (line  66)
* HP-UX 10, ‘lex’ problems:              Public Macros.       (line  95)
* html:                                  Texinfo.             (line  25)
* html <1>:                              Extending.           (line  41)
* HTML output using Texinfo:             Texinfo.             (line   6)
* html-local:                            Extending.           (line  41)
* id:                                    Tags.                (line  43)
* if:                                    Usage of Conditionals.
                                                              (line  36)
* include:                               Basics of Distribution.
                                                              (line  17)
* include <1>:                           Include.             (line   6)
* ‘include’, distribution:               Basics of Distribution.
                                                              (line  17)
* Including ‘Makefile’ fragment:         Include.             (line   6)
* indentation in Makefile.am:            General Operation.   (line  33)
* info:                                  List of Automake options.
                                                              (line  93)
* info <1>:                              Extending.           (line  41)
* info-in-builddir:                      List of Automake options.
                                                              (line  53)
* info-local:                            Extending.           (line  41)
* install:                               Standard Targets.    (line  18)
* install <1>:                           The Two Parts of Install.
                                                              (line  14)
* install <2>:                           Extending.           (line  41)
* Install hook:                          Extending Installation.
                                                              (line  15)
* Install, two parts of:                 The Two Parts of Install.
                                                              (line  14)
* install-data:                          Two-Part Install.    (line  16)
* install-data <1>:                      The Two Parts of Install.
                                                              (line  14)
* install-data <2>:                      Extending.           (line  41)
* install-data-hook:                     Extending.           (line  66)
* install-data-local:                    Extending Installation.
                                                              (line   9)
* install-data-local <1>:                Extending.           (line  41)
* install-dvi:                           Texinfo.             (line  25)
* install-dvi <1>:                       Extending.           (line  41)
* install-dvi-local:                     Extending.           (line  41)
* install-exec:                          Two-Part Install.    (line  16)
* install-exec <1>:                      The Two Parts of Install.
                                                              (line  14)
* install-exec <2>:                      Extending.           (line  41)
* install-exec-hook:                     Extending.           (line  66)
* install-exec-local:                    Extending Installation.
                                                              (line   9)
* install-exec-local <1>:                Extending.           (line  41)
* install-html:                          Texinfo.             (line  25)
* install-html <1>:                      Extending.           (line  41)
* install-html-local:                    Extending.           (line  41)
* install-info:                          Texinfo.             (line  85)
* install-info <1>:                      List of Automake options.
                                                              (line  93)
* install-info <2>:                      Extending.           (line  41)
* ‘install-info’ target:                 Texinfo.             (line  85)
* install-info-local:                    Extending.           (line  41)
* install-man:                           Man Pages.           (line  32)
* install-man <1>:                       List of Automake options.
                                                              (line  99)
* ‘install-man’ target:                  Man Pages.           (line  32)
* install-pdf:                           Texinfo.             (line  25)
* install-pdf <1>:                       Extending.           (line  41)
* install-pdf-local:                     Extending.           (line  41)
* install-ps:                            Texinfo.             (line  25)
* install-ps <1>:                        Extending.           (line  41)
* install-ps-local:                      Extending.           (line  41)
* install-strip:                         Standard Targets.    (line  21)
* install-strip <1>:                     Install Rules for the User.
                                                              (line   7)
* Installation directories, extending list: Uniform.          (line  56)
* Installation support:                  Install.             (line   6)
* Installation, basics:                  Basic Installation.  (line   6)
* installcheck:                          Standard Targets.    (line  33)
* installcheck <1>:                      Extending.           (line  41)
* installcheck-local:                    Extending.           (line  41)
* installdirs:                           Install Rules for the User.
                                                              (line   7)
* installdirs <1>:                       Extending.           (line  41)
* installdirs-local:                     Extending.           (line  41)
* Installing headers:                    Headers.             (line   6)
* Installing scripts:                    Scripts.             (line   6)
* installing versioned binaries:         Extending.           (line  86)
* Interfacing with third-party packages: Third-Party Makefiles.
                                                              (line   6)
* Invocation of ‘aclocal’:               aclocal Invocation.  (line   6)
* Invocation of ‘automake’:              automake Invocation. (line   6)
* Invoking ‘aclocal’:                    aclocal Invocation.  (line   6)
* Invoking ‘automake’:                   automake Invocation. (line   6)
* ‘JAVA’ primary, defined:               Java.                (line   6)
* ‘JAVA’ restrictions:                   Java.                (line  27)
* Java support with gcj:                 Java Support with gcj.
                                                              (line   6)
* Java to bytecode, compilation:         Java.                (line   6)
* Java to native code, compilation:      Java Support with gcj.
                                                              (line   6)
* lazy test execution:                   Parallel Test Harness.
                                                              (line 118)
* ‘LDADD’ and ‘-l’:                      Linking.             (line  70)
* ‘LDFLAGS’ and ‘AM_LDFLAGS’:            Flag Variables Ordering.
                                                              (line  20)
* ‘lex’ problems with HP-UX 10:          Public Macros.       (line  95)
* ‘lex’, multiple lexers:                Yacc and Lex.        (line  68)
* ‘LFLAGS’ and ‘AM_LFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* ‘libltdl’, introduction:               Libtool Concept.     (line  29)
* ‘LIBOBJS’, and Libtool:                LTLIBOBJS.           (line   6)
* ‘LIBOBJS’, example:                    LIBOBJS.             (line   6)
* ‘LIBOBJS’, special handling:           LIBOBJS.             (line   6)
* ‘LIBRARIES’ primary, defined:          A Library.           (line   6)
* libtool convenience libraries:         Libtool Convenience Libraries.
                                                              (line   6)
* libtool libraries, conditional:        Conditional Libtool Libraries.
                                                              (line   6)
* libtool library, definition:           Libtool Concept.     (line   6)
* libtool modules:                       Libtool Modules.     (line   6)
* Libtool modules, default source example: Default _SOURCES.  (line  38)
* ‘libtool’, introduction:               Libtool Concept.     (line   6)
* ‘LIBTOOLFLAGS’ and ‘AM_LIBTOOLFLAGS’:  Flag Variables Ordering.
                                                              (line  20)
* ‘libtoolize’ and ‘autoreconf’:         Error required file ltmain.sh not found.
                                                              (line   6)
* ‘libtoolize’, no longer run by ‘automake’: Error required file ltmain.sh not found.
                                                              (line   6)
* Limitations of automake parser:        General Operation.   (line  33)
* Linking Fortran 77 with C and C++:     Mixing Fortran 77 With C and C++.
                                                              (line   6)
* ‘LISP’ primary, defined:               Emacs Lisp.          (line   6)
* ‘LN_S’ example:                        Extending.           (line  86)
* local targets:                         Extending.           (line  37)
* ‘LTALLOCA’, special handling:          LTLIBOBJS.           (line   6)
* ‘LTLIBOBJS’, special handling:         LTLIBOBJS.           (line   6)
* ‘LTLIBRARIES’ primary, defined:        Libtool Libraries.   (line   6)
* ‘ltmain.sh’ not found:                 Error required file ltmain.sh not found.
                                                              (line   6)
* ‘m4_include’, distribution:            Basics of Distribution.
                                                              (line  17)
* Macro search path:                     Macro Search Path.   (line   6)
* macro serial numbers:                  Serials.             (line   6)
* Macros Automake recognizes:            Optional.            (line   6)
* maintainer-clean-local:                Clean.               (line  15)
* ‘make check’:                          Tests.               (line   6)
* ‘make clean’ support:                  Clean.               (line   6)
* ‘make dist’:                           Basics of Distribution.
                                                              (line   6)
* ‘make distcheck’:                      Checking the Distribution.
                                                              (line   6)
* ‘make distclean’, diagnostic:          Errors with distclean.
                                                              (line   6)
* ‘make distcleancheck’:                 Checking the Distribution.
                                                              (line  70)
* ‘make distuninstallcheck’:             Checking the Distribution.
                                                              (line 106)
* ‘make install’ support:                Install.             (line   6)
* ‘make installcheck’, testing ‘--help’ and ‘--version’: List of Automake options.
                                                              (line 129)
* Make rules, overriding:                General Operation.   (line  46)
* Make targets, overriding:              General Operation.   (line  46)
* ‘Makefile’ fragment, including:        Include.             (line   6)
* Makefile.am, first line:               General Operation.   (line  74)
* ‘Makefile.am’, Hello World:            amhello's Makefile.am Setup Explained.
                                                              (line   6)
* Man page renaming, avoiding:           Man Pages.           (line  54)
* ‘MANS’ primary, defined:               Man Pages.           (line   6)
* many outputs, rules with:              Multiple Outputs.    (line   6)
* ‘mdate-sh’:                            Texinfo.             (line  35)
* MinGW cross-compilation example:       Cross-Compilation.   (line  25)
* ‘missing’, purpose:                    maintainer-mode.     (line   9)
* Mixed language example:                Mixing Fortran 77 With C and C++.
                                                              (line  34)
* Mixing Fortran 77 with C and C++:      Mixing Fortran 77 With C and C++.
                                                              (line   6)
* Mixing Fortran 77 with C and/or C++:   Mixing Fortran 77 With C and C++.
                                                              (line   6)
* ‘mkdir -p’, macro check:               Obsolete Macros.     (line  14)
* modules, libtool:                      Libtool Modules.     (line   6)
* mostlyclean:                           Extending.           (line  41)
* mostlyclean-local:                     Clean.               (line  15)
* mostlyclean-local <1>:                 Extending.           (line  41)
* multiple configurations, example:      VPATH Builds.        (line  46)
* Multiple ‘configure.ac’ files:         automake Invocation. (line   6)
* Multiple ‘lex’ lexers:                 Yacc and Lex.        (line  68)
* multiple outputs, rules with:          Multiple Outputs.    (line   6)
* Multiple ‘yacc’ parsers:               Yacc and Lex.        (line  68)
* Nested packages:                       Nested Packages.     (line   6)
* Nesting packages:                      Subpackages.         (line   6)
* no-define:                             Public Macros.       (line  55)
* no-define <1>:                         List of Automake options.
                                                              (line  58)
* no-dependencies:                       Dependencies.        (line  34)
* no-dependencies <1>:                   List of Automake options.
                                                              (line  66)
* no-dist:                               List of Automake options.
                                                              (line  73)
* no-dist-gzip:                          List of Automake options.
                                                              (line  77)
* no-dist-gzip <1>:                      List of Automake options.
                                                              (line  77)
* no-exeext:                             List of Automake options.
                                                              (line  80)
* no-installinfo:                        Texinfo.             (line  85)
* no-installinfo <1>:                    List of Automake options.
                                                              (line  90)
* ‘no-installinfo’ option:               Texinfo.             (line  85)
* no-installman:                         Man Pages.           (line  32)
* no-installman <1>:                     List of Automake options.
                                                              (line  96)
* ‘no-installman’ option:                Man Pages.           (line  32)
* no-texinfo.tex:                        List of Automake options.
                                                              (line 106)
* ‘nobase_’ and ‘dist_’ or ‘nodist_’:    Alternative.         (line  29)
* ‘nobase_’ prefix:                      Alternative.         (line  23)
* ‘nodist_’ and ‘nobase_’:               Alternative.         (line  29)
* ‘nodist_’ and ‘notrans_’:              Man Pages.           (line  63)
* ‘noinst_’ primary prefix, definition:  Uniform.             (line  90)
* Non-GNU packages:                      Strictness.          (line   6)
* Non-standard targets:                  General Operation.   (line  12)
* nostdinc:                              List of Automake options.
                                                              (line 102)
* ‘notrans_’ and ‘dist_’ or ‘nodist_’:   Man Pages.           (line  63)
* ‘notrans_’ prefix:                     Man Pages.           (line  54)
* ‘OBJCFLAGS’ and ‘AM_OBJCFLAGS’:        Flag Variables Ordering.
                                                              (line  20)
* ‘OBJCXXFLAGS’ and ‘AM_OBJCXXFLAGS’:    Flag Variables Ordering.
                                                              (line  20)
* Objective C support:                   Objective C Support. (line   6)
* Objective C++ support:                 Objective C++ Support.
                                                              (line   6)
* Objects in subdirectory:               Program and Library Variables.
                                                              (line  51)
* obsolete macros:                       Obsolete Macros.     (line   6)
* optimized build, example:              VPATH Builds.        (line  46)
* Option, ‘--warnings=CATEGORY’:         List of Automake options.
                                                              (line 211)
* Option, ‘-WCATEGORY’:                  List of Automake options.
                                                              (line 211)
* Option, ‘check-news’:                  List of Automake options.
                                                              (line  14)
* Option, ‘dejagnu’:                     List of Automake options.
                                                              (line  18)
* Option, ‘dist-bzip2’:                  List of Automake options.
                                                              (line  22)
* Option, ‘dist-lzip’:                   List of Automake options.
                                                              (line  25)
* Option, ‘dist-shar’:                   List of Automake options.
                                                              (line  34)
* Option, ‘dist-tarZ’:                   List of Automake options.
                                                              (line  39)
* Option, ‘dist-xz’:                     List of Automake options.
                                                              (line  28)
* Option, ‘dist-zip’:                    List of Automake options.
                                                              (line  31)
* Option, ‘filename-length-max=99’:      List of Automake options.
                                                              (line  44)
* Option, ‘foreign’:                     List of Automake options.
                                                              (line   9)
* Option, ‘gnits’:                       List of Automake options.
                                                              (line   9)
* Option, ‘gnu’:                         List of Automake options.
                                                              (line   9)
* Option, ‘info-in-builddir’:            List of Automake options.
                                                              (line  53)
* Option, ‘no-define’:                   List of Automake options.
                                                              (line  58)
* Option, ‘no-dependencies’:             List of Automake options.
                                                              (line  66)
* Option, ‘no-dist’:                     List of Automake options.
                                                              (line  73)
* Option, ‘no-dist-gzip’:                List of Automake options.
                                                              (line  77)
* Option, ‘no-exeext’:                   List of Automake options.
                                                              (line  80)
* Option, ‘no-installinfo’:              Texinfo.             (line  85)
* Option, ‘no-installinfo’ <1>:          List of Automake options.
                                                              (line  90)
* Option, ‘no-installman’:               Man Pages.           (line  32)
* Option, ‘no-installman’ <1>:           List of Automake options.
                                                              (line  96)
* Option, ‘no-texinfo.tex’:              List of Automake options.
                                                              (line 106)
* Option, ‘nostdinc’:                    List of Automake options.
                                                              (line 102)
* Option, ‘parallel-tests’:              List of Automake options.
                                                              (line 114)
* Option, ‘readme-alpha’:                List of Automake options.
                                                              (line 120)
* Option, ‘serial-tests’:                List of Automake options.
                                                              (line 110)
* Option, ‘tar-pax’:                     List of Automake options.
                                                              (line 159)
* Option, ‘tar-ustar’:                   List of Automake options.
                                                              (line 159)
* Option, ‘tar-v7’:                      List of Automake options.
                                                              (line 159)
* Option, VERSION:                       List of Automake options.
                                                              (line 206)
* Option, warnings:                      List of Automake options.
                                                              (line 211)
* Options, ‘aclocal’:                    aclocal Options.     (line   6)
* Options, ‘automake’:                   automake Invocation. (line  37)
* Options, ‘std-options’:                List of Automake options.
                                                              (line 129)
* Options, ‘subdir-objects’:             List of Automake options.
                                                              (line 150)
* Ordering flag variables:               Flag Variables Ordering.
                                                              (line   6)
* Overriding make rules:                 General Operation.   (line  46)
* Overriding make targets:               General Operation.   (line  46)
* Overriding make variables:             General Operation.   (line  51)
* overriding rules:                      Extending.           (line  26)
* overriding semantics:                  Extending.           (line  26)
* ‘PACKAGE’, directory:                  Uniform.             (line  19)
* ‘PACKAGE’, prevent definition:         Public Macros.       (line  55)
* Packages, nested:                      Nested Packages.     (line   6)
* Packages, preparation:                 Preparing Distributions.
                                                              (line   6)
* Parallel build trees:                  VPATH Builds.        (line   6)
* parallel-tests:                        List of Automake options.
                                                              (line 114)
* Path stripping, avoiding:              Alternative.         (line  23)
* pax format:                            List of Automake options.
                                                              (line 159)
* pdf:                                   Texinfo.             (line  25)
* pdf <1>:                               Extending.           (line  41)
* PDF output using Texinfo:              Texinfo.             (line   6)
* pdf-local:                             Extending.           (line  41)
* Per-object flags, emulated:            Per-Object Flags.    (line   6)
* per-target compilation flags, defined: Program and Library Variables.
                                                              (line 182)
* ‘pkgdatadir’, defined:                 Uniform.             (line  19)
* ‘pkgincludedir’, defined:              Uniform.             (line  19)
* ‘pkglibdir’, defined:                  Uniform.             (line  19)
* ‘pkglibexecdir’, defined:              Uniform.             (line  19)
* Preparing distributions:               Preparing Distributions.
                                                              (line   6)
* Preprocessing Fortran 77:              Preprocessing Fortran 77.
                                                              (line   6)
* Primary variable, ‘DATA’:              Data.                (line   6)
* Primary variable, defined:             Uniform.             (line  11)
* Primary variable, ‘HEADERS’:           Headers.             (line   6)
* Primary variable, ‘JAVA’:              Java.                (line   6)
* Primary variable, ‘LIBRARIES’:         A Library.           (line   6)
* Primary variable, ‘LISP’:              Emacs Lisp.          (line   6)
* Primary variable, ‘LTLIBRARIES’:       Libtool Libraries.   (line   6)
* Primary variable, ‘MANS’:              Man Pages.           (line   6)
* Primary variable, ‘PROGRAMS’:          Uniform.             (line  11)
* Primary variable, ‘PYTHON’:            Python.              (line   6)
* Primary variable, ‘SCRIPTS’:           Scripts.             (line   6)
* Primary variable, ‘SOURCES’:           Program Sources.     (line  32)
* Primary variable, ‘TEXINFOS’:          Texinfo.             (line   6)
* ‘PROGRAMS’ primary variable:           Uniform.             (line  11)
* Programs, auxiliary:                   Auxiliary Programs.  (line   6)
* ‘PROGRAMS’, ‘bindir’:                  Program Sources.     (line   6)
* Programs, conditional:                 Conditional Programs.
                                                              (line   6)
* Programs, renaming during installation: Renaming.           (line   6)
* ‘prog_LDADD’, defined:                 Linking.             (line  12)
* Proxy ‘Makefile’ for third-party packages: Third-Party Makefiles.
                                                              (line 128)
* ps:                                    Texinfo.             (line  25)
* ps <1>:                                Extending.           (line  41)
* PS output using Texinfo:               Texinfo.             (line   6)
* ps-local:                              Extending.           (line  41)
* ‘PYTHON’ primary, defined:             Python.              (line   6)
* Ratfor programs:                       Preprocessing Fortran 77.
                                                              (line   6)
* read-only source tree:                 VPATH Builds.        (line  89)
* readme-alpha:                          List of Automake options.
                                                              (line 120)
* ‘README-alpha’:                        Gnits.               (line  42)
* rebuild rules:                         Rebuilding.          (line   6)
* rebuild rules <1>:                     CVS.                 (line   9)
* recheck:                               Parallel Test Harness.
                                                              (line 130)
* Recognized macros by Automake:         Optional.            (line   6)
* Recursive operation of Automake:       General Operation.   (line  58)
* recursive targets and third-party ‘Makefile’s: Third-Party Makefiles.
                                                              (line  15)
* Register test case result:             Log files generation and test results recording.
                                                              (line  24)
* Register test result:                  Log files generation and test results recording.
                                                              (line  24)
* Renaming programs:                     Renaming.            (line   6)
* Reporting bugs:                        Introduction.        (line  30)
* Requirements of Automake:              Requirements.        (line   6)
* Requirements, Automake:                Introduction.        (line  26)
* Restrictions for ‘JAVA’:               Java.                (line  27)
* reStructuredText field, ‘:copy-in-global-log:’: Log files generation and test results recording.
                                                              (line  44)
* reStructuredText field, ‘:recheck:’:   Log files generation and test results recording.
                                                              (line  38)
* reStructuredText field, ‘:test-global-result:’: Log files generation and test results recording.
                                                              (line  54)
* reStructuredText field, ‘:test-result:’: Log files generation and test results recording.
                                                              (line  24)
* ‘RFLAGS’ and ‘AM_RFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* rules with multiple outputs:           Multiple Outputs.    (line   6)
* rules, conflicting:                    Extending.           (line  14)
* rules, debugging:                      Debugging Make Rules.
                                                              (line   6)
* rules, overriding:                     Extending.           (line  26)
* Scanning ‘configure.ac’:               configure.           (line   6)
* ‘SCRIPTS’ primary, defined:            Scripts.             (line   6)
* ‘SCRIPTS’, installation directories:   Scripts.             (line  18)
* Selecting the linker automatically:    How the Linker is Chosen.
                                                              (line   6)
* serial number and ‘--install’:         aclocal Options.     (line  38)
* serial numbers in macros:              Serials.             (line   6)
* serial-tests:                          List of Automake options.
                                                              (line 110)
* ‘serial-tests’, Using:                 Serial Test Harness. (line   6)
* Shared libraries, support for:         A Shared Library.    (line   6)
* Silencing ‘make’:                      Silencing Make.      (line   6)
* Silent ‘make’:                         Silencing Make.      (line   6)
* Silent ‘make’ rules:                   Silencing Make.      (line   6)
* Silent rules:                          Silencing Make.      (line   6)
* silent rules and libtool:              Automake Silent Rules.
                                                              (line  59)
* ‘site.exp’:                            DejaGnu Tests.       (line  26)
* source tree and build tree:            VPATH Builds.        (line   6)
* source tree, read-only:                VPATH Builds.        (line  89)
* ‘SOURCES’ primary, defined:            Program Sources.     (line  32)
* Special Automake comment:              General Operation.   (line  68)
* Staged installation:                   DESTDIR.             (line  14)
* std-options:                           List of Automake options.
                                                              (line 129)
* Strictness, command line:              automake Invocation. (line  37)
* Strictness, defined:                   Strictness.          (line  10)
* Strictness, ‘foreign’:                 Strictness.          (line  10)
* Strictness, ‘gnits’:                   Strictness.          (line  10)
* Strictness, ‘gnu’:                     Strictness.          (line  10)
* su, before ‘make install’:             Basic Installation.  (line  49)
* subdir-objects:                        List of Automake options.
                                                              (line 150)
* Subdirectories, building conditionally: Conditional Subdirectories.
                                                              (line   6)
* Subdirectories, configured conditionally: Unconfigured Subdirectories.
                                                              (line   6)
* Subdirectories, not distributed:       Unconfigured Subdirectories.
                                                              (line  55)
* Subdirectory, objects in:              Program and Library Variables.
                                                              (line  51)
* ‘SUBDIRS’ and ‘AC_SUBST’:              Subdirectories with AC_SUBST.
                                                              (line   6)
* ‘SUBDIRS’ and ‘AM_CONDITIONAL’:        Subdirectories with AM_CONDITIONAL.
                                                              (line   6)
* ‘SUBDIRS’, conditional:                Conditional Subdirectories.
                                                              (line   6)
* ‘SUBDIRS’, explained:                  Subdirectories.      (line   6)
* Subpackages:                           Nested Packages.     (line   6)
* Subpackages <1>:                       Subpackages.         (line   6)
* suffix ‘.la’, defined:                 Libtool Concept.     (line   6)
* suffix ‘.lo’, defined:                 Libtool Concept.     (line  15)
* ‘SUFFIXES’, adding:                    Suffixes.            (line   6)
* Support for C++:                       C++ Support.         (line   6)
* Support for Fortran 77:                Fortran 77 Support.  (line   6)
* Support for Fortran 9x:                Fortran 9x Support.  (line   6)
* Support for GNU Gettext:               gettext.             (line   6)
* Support for Java with gcj:             Java Support with gcj.
                                                              (line   6)
* Support for Objective C:               Objective C Support. (line   6)
* Support for Objective C++:             Objective C++ Support.
                                                              (line   6)
* Support for Unified Parallel C:        Unified Parallel C Support.
                                                              (line   6)
* Support for Vala:                      Vala Support.        (line   6)
* tags:                                  Tags.                (line   9)
* ‘TAGS’ support:                        Tags.                (line   6)
* ‘tar’ formats:                         List of Automake options.
                                                              (line 159)
* tar-pax:                               List of Automake options.
                                                              (line 159)
* tar-ustar:                             List of Automake options.
                                                              (line 159)
* tar-v7:                                List of Automake options.
                                                              (line 159)
* Target, ‘install-info’:                Texinfo.             (line  85)
* Target, ‘install-man’:                 Man Pages.           (line  32)
* test case:                             Generalities about Testing.
                                                              (line  11)
* Test case result, registering:         Log files generation and test results recording.
                                                              (line  24)
* test failure:                          Generalities about Testing.
                                                              (line  25)
* test harness:                          Generalities about Testing.
                                                              (line  18)
* test metadata:                         Parallel Test Harness.
                                                              (line  12)
* test pass:                             Generalities about Testing.
                                                              (line  25)
* Test result, registering:              Log files generation and test results recording.
                                                              (line  24)
* test skip:                             Generalities about Testing.
                                                              (line  29)
* Test suites:                           Tests.               (line   6)
* Tests, expected failure:               Scripts-based Testsuites.
                                                              (line  32)
* testsuite harness:                     Generalities about Testing.
                                                              (line  18)
* Testsuite progress on console:         Scripts-based Testsuites.
                                                              (line  45)
* Texinfo flag, ‘EDITION’:               Texinfo.             (line  35)
* Texinfo flag, ‘UPDATED’:               Texinfo.             (line  35)
* Texinfo flag, ‘UPDATED-MONTH’:         Texinfo.             (line  35)
* Texinfo flag, ‘VERSION’:               Texinfo.             (line  35)
* ‘texinfo.tex’:                         Texinfo.             (line  70)
* ‘TEXINFOS’ primary, defined:           Texinfo.             (line   6)
* third-party files and CVS:             CVS.                 (line 167)
* Third-party packages, interfacing with: Third-Party Makefiles.
                                                              (line   6)
* timestamps and CVS:                    CVS.                 (line  28)
* Transforming program names:            Renaming.            (line   6)
* trees, source vs. build:               VPATH Builds.        (line   6)
* ‘true’ Example:                        true.                (line   6)
* underquoted ‘AC_DEFUN’:                Extending aclocal.   (line  36)
* unexpected pass:                       Generalities about Testing.
                                                              (line  39)
* unexpected test pass:                  Generalities about Testing.
                                                              (line  39)
* Unified Parallel C support:            Unified Parallel C Support.
                                                              (line   6)
* Uniform naming scheme:                 Uniform.             (line   6)
* uninstall:                             Standard Targets.    (line  24)
* uninstall <1>:                         Install Rules for the User.
                                                              (line   7)
* uninstall <2>:                         Extending.           (line  41)
* uninstall-hook:                        Extending.           (line  66)
* uninstall-local:                       Extending.           (line  41)
* Unit tests:                            Parallel Test Harness.
                                                              (line 154)
* Unpacking:                             Basic Installation.  (line  27)
* ‘UPCFLAGS’ and ‘AM_UPCFLAGS’:          Flag Variables Ordering.
                                                              (line  20)
* ‘UPDATED’ Texinfo flag:                Texinfo.             (line  35)
* ‘UPDATED-MONTH’ Texinfo flag:          Texinfo.             (line  35)
* Use Cases for the GNU Build System:    Use Cases.           (line   6)
* user variables:                        User Variables.      (line   6)
* Using ‘aclocal’:                       configure.           (line   6)
* ustar format:                          List of Automake options.
                                                              (line 159)
* v7 ‘tar’ format:                       List of Automake options.
                                                              (line 159)
* Vala Support:                          Vala Support.        (line   6)
* variables, conflicting:                Extending.           (line  14)
* Variables, overriding:                 General Operation.   (line  51)
* variables, reserved for the user:      User Variables.      (line   6)
* ‘VERSION’ Texinfo flag:                Texinfo.             (line  35)
* ‘VERSION’, prevent definition:         Public Macros.       (line  55)
* ‘version.m4’, example:                 Rebuilding.          (line  12)
* ‘version.sh’, example:                 Rebuilding.          (line  12)
* versioned binaries, installing:        Extending.           (line  86)
* VPATH builds:                          VPATH Builds.        (line   6)
* wildcards:                             Wildcards.           (line   6)
* Windows:                               EXEEXT.              (line   6)
* xfail:                                 Generalities about Testing.
                                                              (line  39)
* xpass:                                 Generalities about Testing.
                                                              (line  39)
* ‘yacc’, multiple parsers:              Yacc and Lex.        (line  68)
* ‘YFLAGS’ and ‘AM_YFLAGS’:              Flag Variables Ordering.
                                                              (line  20)
* ‘ylwrap’:                              Yacc and Lex.        (line  68)
* ‘zardoz’ example:                      Complete.            (line  35)