   This file documents GNU automake 1.7.3

   Copyright 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 Free
Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that this permission notice may be stated in a
translation approved by the Foundation.

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

Basics of distribution
======================

   The `dist' target in the generated `Makefile.in' can be used to
generate a gzip'd `tar' file and other flavors of archive for
distribution.  The files is named based on the `PACKAGE' and `VERSION'
variables defined by `AM_INIT_AUTOMAKE' (see Macros); more
precisely the gzip'd `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's and `Makefile.in's.  Automake also has a
built-in list of commonly used files which 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'.  Also, files which 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.

   Still, sometimes there are files which 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 CVS/RCS version control files.  We recommend against using
this feature.

   If you define `SUBDIRS', Automake will recursively include the
subdirectories in the distribution.  If `SUBDIRS' is defined
conditionally (see 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 (see Top level).

Fine-grained distribution control
=================================

   Sometimes you need tighter control over what does _not_ go into the
distribution; for instance you might have source files which are
generated and which 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

The dist hook
=============

   Occasionally it is useful to be able to change the distribution
before it is packaged up.  If the `dist-hook' target exists, it is run
after the distribution directory is filled, but before the actual tar
(or shar) file is created.  One way to use this is for distributing
files in subdirectories for which a new `Makefile.am' is overkill:

     dist-hook:
             mkdir $(distdir)/random
             cp -p $(srcdir)/random/a1 $(srcdir)/random/a2 $(distdir)/random

   Another way to 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 -name CVS`

Checking the distribution
=========================

   Automake also generates a `distcheck' target which can be of help to
ensure that a given distribution will actually work.  `distcheck' makes
a distribution, then tries to do a `VPATH' build, run the testsuite,
and finally make another tarfile to ensure the distribution is
self-contained.

   Building the package involves running `./configure'.  If you need to
supply additional flags to `configure', define them in the
`DISTCHECK_CONFIGURE_FLAGS' variable, either in your top-level
`Makefile.am', or on the command line when invoking `make'.

   If the target `distcheck-hook' is defined in your `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.

   Speaking about potential distribution errors, `distcheck' will also
ensure that the `distclean' target 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 (see
Clean).

   The `distcleancheck' behaviour should be ok for most packages,
otherwise you have the possibility to override the definitition of
either the `distcleancheck' target, 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 which 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)/{} || echo {}' ';'

   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 a FAQ entry about this (see distcleancheck), make sure you
read it before playing with `distcleancheck_listfiles'.

   `distcheck' also checks that the `uninstall' target 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 targets.

   By default, the checking is done by the `distuninstallcheck' target,
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:
             @:

The types of distributions
==========================

   Automake generates a `.tar.gz' file when asked to create a
distribution and other archives formats, see Options.  The target
`dist-gzip' generates the `.tar.gz' file only.

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

   Automake supports two forms of test suites.

Simple Tests
============

   If the variable `TESTS' is defined, its value is taken to be a list
of programs to run in order to do the testing.  The programs can either
be derived objects or source objects; the generated rule will look both
in `srcdir' and `.'.  Programs needing data files should look for them
in `srcdir' (which is both an environment variable and a make variable)
so they work when building in a separate directory (see Build Directories (autoconf)),
and in particular for the
`distcheck' target (see Dist).

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

   The variable `TESTS_ENVIRONMENT' can be used to set environment
variables for the test run; the environment variable `srcdir' is set in
the rule.  If all your test programs are scripts, you can also set
`TESTS_ENVIRONMENT' to an invocation of the shell (e.g.  `$(SHELL)
-x'); this can be useful for debugging the tests.

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

   Automake ensures that each program listed in `TESTS' is built before
any tests are run; you can list both source and derived programs in
`TESTS'.  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.

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 which 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" (see 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.

   For more information regarding DejaGnu test suites, see dejagnu.

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

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

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

   Various features of Automake can be controlled by options in the
`Makefile.am'.  Such options are applied on a per-`Makefile' basis when
listed in a special `Makefile' variable named `AUTOMAKE_OPTIONS'.  They
are applied globally to all processed `Makefiles' when listed in the
first argument of `AM_INIT_AUTOMAKE' in `configure.in'.  Currently
understood options are:

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

`ansi2knr'
`PATH/ansi2knr'
     Turn on automatic de-ANSI-fication.  See ANSI.  If preceded by
     a path, the generated `Makefile.in' will look in the specified
     directory to find the `ansi2knr' program.  The path should be a
     relative path to another directory in the same distribution
     (Automake currently does not check this).

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

`dejagnu'
     Cause `dejagnu'-specific rules to be generated.  See Tests.

`dist-bzip2'
     Generate a `dist-bzip2' target, creating a bzip2 tar archive of the
     distribution.  `dist' will create it in addition to the other
     formats.  bzip2 archives are frequently smaller than gzipped
     archives.

`dist-shar'
     Generate a `dist-shar' target, creating a shar archive of the
     distribution.  `dist' will create it in addition to the other
     formats.

`dist-zip'
     Generate a `dist-zip' target, creating a zip archive of the
     distribution.  `dist' will create it in addition to the other
     formats.

`dist-tarZ'
     Generate a `dist-tarZ' target, creating a compressed tar archive of
     the distribution.  `dist' will create it in addition to the other
     formats.

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

`no-dependencies'
     This is similar to using `--include-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
     Dependencies.  In this case the effect is to effectively disable
     automatic dependency tracking.

`no-exeext'
     If your `Makefile.am' defines a target `foo', it will override 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 which
     are ordinarily automatically provided by Automake.

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

`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' target 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 sh-utils) is never
     successful, even for `--help' or `--version'.  You can list such
     programs in the variable `AM_INSTALLCHECK_STD_OPTIONS_EXEMPT'.
     Programs (not scripts) listed in this variable should be suffixed
     by `$(EXEEXT)' for the sake of Win32 or OS/2.  For instance
     suppose we build `false' as a program but `true.sh' as a script,
     and that neither of them support `--help' or `--version':

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

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

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
     (see Invoking Automake).  This allows you to enable or disable
     some warning categories on a per-file basis.  You can also setup
     some warnings for your entire project; for instance try
     `AM_INIT_AUTOMAKE([-Wall])' in your `configure.in'.

   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.in'.  See Macros.

Miscellaneous Rules
*******************

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

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' targets will be generated for the directory.

   At the topmost directory of a multi-directory package, a `tags'
target file will be generated which, when run, will generate a `TAGS'
file that includes by reference all `TAGS' files from subdirectories.

   The `tags' target will also be generated if the variable
`ETAGS_ARGS' is defined.  This variable is intended for use in
directories which 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 filenames to `ETAGS_ARGS', you will probably also want to
set `TAGS_DEPENDENCIES'.  The contents of this variable are added
directly to the dependencies for the `tags' target.

   Automake also generates a `ctags' target which 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' target which will run `mkid' on
the source.  This is only supported on a directory-by-directory basis.

   Automake also supports the GNU Global Tags program
(http://www.gnu.org/software/global/).  The `GTAGS' target runs Global
Tags automatically and puts the result in the top build directory.  The
variable `GTAGS_ARGS' holds arguments which are passed to `gtags'.

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 which could compile `.foo'
files to `.o' files.  You would simply define an 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 which extensions you are defining your
suffix rule for.  This usually happens when your extensions 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 to
misinterpret `.idlC.cpp:' as an attempt to transform `.idlC' into
`.cpp'.

     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.

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

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

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

Include
*******

   Automake supports an `include' directive which 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 which is found relative to the current source
     directory.

`include $(top_srcdir)/file'
     Include a fragment which 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
there are needed to rebuild `Makefile.in'.

Conditionals
************

   Automake supports a simple type of conditionals.

   Before using a conditional, you must define it by using
`AM_CONDITIONAL' in the `configure.in' file (see 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' which
     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 which the user provides to
the `configure' script.  Here is an example of how to write a
conditional which 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
(see 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 which is closed
by an `end':

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

Unbalanced conditions are errors.

   Note that conditionals in Automake 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.

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.

   * 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 targets; 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 (see 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.

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

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

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

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

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

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

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

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

   * `--foreign' is implied.

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

   * The macros `AM_MAINTAINER_MODE' and `AM_CYGWIN32' are required.

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

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

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

   Automake's implicit copying semantics means that many problems can be
worked around by simply adding some `make' targets and rules to
`Makefile.in'.  Automake will ignore these additions.

   There are some caveats to doing this.  Although you can overload a
target already used by Automake, it is often inadvisable, particularly
in the topmost directory of a package with subdirectories.  However,
various useful targets have a `-local' version you can specify in your
`Makefile.in'.  Automake will supplement the standard target with these
user-supplied targets.

   The targets that support a local version are `all', `info', `dvi',
`ps', `pdf', `check', `install-data', `install-exec', `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 install a file in `/etc':

     install-data-local:
             $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile

   Some targets also have a way to run another target, called a "hook",
after their 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 $(DESTDIR)$(bindir)/proglink

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.

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

   Note that `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 which work with Automake 1.6 should also work with 1.6.1; after
all, this is what people expect from bug fix releases.

   Note that 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.in':

       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 a undocumented feature, contact
<automake@gnu.org> and try to get it documented and exercised by the
test-suite.

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

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

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

Background: distributed generated files
---------------------------------------

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

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

   As generated files shipped in packages are up-to-date, and because
`tar' preserves timestamps, 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 which 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 alphabetical
order, `configure.in' will appear older than `configure' after a `cvs
update' that updates both files, even if `configure' was newer than
`configure.in' when it was checked in.  Calling `make' will then
trigger a spurious rebuild of `configure'.

Living with CVS in Autoconfiscated projects
-------------------------------------------

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

All files in CVS
................

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

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

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

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

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

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

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

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

        * Or `configure.in' uses `AM_MAINTAINER_MODE', which will
          disable all these rebuild rules by default.  This is further
          discussed in 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
     rebuilt `Makefile.in', and then decide 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' make the copy of `Makefile.in'
     out-of-date.  Since CVS processes files alphabetically, when
     another developer `cvs update' his or her tree, `Makefile.in' will
     happen to be newer than `Makefile.am'.  This other developer will
     not see `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 which are
`Makefile' targets (or _derived_ files in Make terminology).

   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 there own versions
of this tool.

Third-party files
-----------------

   Another class of files not discussed here (because they do not cause
timestamp issues) are files which 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 CVS Issues (gettext).

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

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

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

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

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

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

   `AM_MAINTAINER_MODE' disables the so called "rebuild rules" by
default.  If you have `AM_MAINTAINER_MODE' in `configure.ac', and run
`./configure && make', then `make' will *never* attempt to rebuilt
`configure', `Makefile.in's, Lex or Yacc outputs, etc.  I.e., this
disables build rules for files which are usually distributed and that
users should normally not have to update.

   If you run `./configure --enable-maintainer-mode', then these
rebuild rules will be active.

   People use `AM_MAINTAINER_MODE' either because they do want their
users (or themselves) annoyed by timestamps lossage (see 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 `AM_MAINTAINER_MODE'.  Most of them relate to insecurity.  By
removing dependencies you get non-dependable builds: change 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 CVS, and
because `missing' isn't enough if you have the wrong version of the
tools.

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

   Developers are lazy.  They often would like to use wildcards in
`Makefile.am's, so they don't need to remember they have 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 easy to distribute files by mistake.  For
     instance some code a developer is experimenting with (a test case,
     say) but which 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 at many places,
     but forget to commit it.  Another developer then checkout the
     incomplete project and is able to run `make dist' successfully,
     even though a file is missing.

   * Listing files, you control *exactly* what you distribute.  If some
     file that should be distributed is missing from your tree, `make
     dist' will complain.  Besides, you don't distribute more than what
     you listed.

   * Finally it's really hard to `forget' adding a file to
     `Makefile.am', because if you don't add it, it doesn't get
     compiled nor installed, so you can't even test it.

   Still, these are philosophic 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 the main technical issue: portability.

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

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

   Compared to editing `Makefile.am', this really little win.  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 add
support for this syntax.  Some people use scripts to generated 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 need 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 blackbox comparable to `AC_SUBST'ed variables as far
Automake is concerned.

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