source: trunk/essentials/sys-devel/automake-1.4/automake.texi@ 3253

\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename automake.info
@settitle automake
@setchapternewpage off
@c %**end of header

@include version.texi

@dircategory GNU admin
@direntry
* automake: (automake).         Making Makefile.in's
@end direntry

@dircategory Individual utilities
@direntry
* aclocal: (automake)Invoking aclocal.          Generating aclocal.m4
@end direntry

@ifinfo
This file documents GNU automake @value{VERSION}

Copyright (C) 1995, 96, 97, 98 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.

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph


@end ignore
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.
@end ifinfo


@titlepage
@title GNU Automake
@subtitle For version @value{VERSION}, @value{UPDATED}
@author David MacKenzie and Tom Tromey

@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1995, 96 Free Software Foundation, Inc.
@sp 2
This is the first edition of the GNU Automake documentation,@*
and is consistent with GNU Automake @value{VERSION}.@*
@sp 2
Published by the Free Software Foundation @*
59 Temple Place - Suite 330, @*
Boston, MA 02111-1307 USA @*

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 Free Software Foundation.
@end titlepage

@c Define an index of configure output variables.
@defcodeindex ov
@c Define an index of configure variables.
@defcodeindex cv
@c Define an index of options.
@defcodeindex op
@c Define an index of targets.
@defcodeindex tr
@c Define an index of commands.
@defcodeindex cm

@c Put the macros and variables into their own index.
@c @syncodeindex fn cp
@syncodeindex ov vr
@syncodeindex cv vr
@syncodeindex fn vr

@c Put everything else into one index (arbitrarily chosen to be the concept index).
@syncodeindex op cp
@syncodeindex tr cp
@syncodeindex cm cp

@ifinfo
@node Top, Introduction, (dir), (dir)
@comment  node-name,  next,  previous,  up
@top GNU Automake

This file documents the GNU Automake package for creating GNU
Standards-compliant Makefiles from template files.  This edition
documents version @value{VERSION}.

@menu
* Introduction::                Automake's purpose
* Generalities::                General ideas
* Examples::                    Some example packages
* Invoking Automake::           Creating a Makefile.in
* configure::                   Scanning configure.in
* Top level::                   The top-level Makefile.am
* Programs::                    Building programs and libraries
* Other objects::               Other derived objects
* Other GNU Tools::             Other GNU Tools
* Documentation::               Building documentation
* Install::                     What gets installed
* Clean::                       What gets cleaned
* Dist::                        What goes in a distribution
* Tests::                       Support for test suites
* Options::                     Changing Automake's behavior
* Miscellaneous::               Miscellaneous rules
* Include::                     Including extra files in an Automake template.
* Conditionals::                Conditionals
* Gnits::                       The effect of @code{--gnu} and @code{--gnits}
* Cygnus::                      The effect of @code{--cygnus}
* Extending::                   Extending Automake
* Distributing::                Distributing the Makefile.in
* Future::                      Some ideas for the future
* Macro and Variable Index::    
* General Index::               
@end menu

@end ifinfo


@node Introduction, Generalities, Top, Top
@chapter Introduction

Automake is a tool for automatically generating @file{Makefile.in}s from
files called @file{Makefile.am}.  Each @file{Makefile.am} is basically a
series of @code{make} macro definitions (with rules being thrown in
occasionally).  The generated @file{Makefile.in}s are compliant with the
GNU Makefile standards.

@cindex GNU Makefile standards

The GNU Makefile Standards Document
(@pxref{Makefile Conventions, , , standards, The GNU Coding Standards})
is long, complicated, and subject to change.  The goal of Automake is to
remove the burden of Makefile maintenance from the back of the
individual GNU maintainer (and put it on the back of the Automake
maintainer).

The typical Automake input file is simply a series of macro definitions.
Each such file is processed to create a @file{Makefile.in}.  There
should generally be one @file{Makefile.am} per directory of a project.

@cindex Constraints of Automake
@cindex Automake constraints

Automake does constrain a project in certain ways; for instance it
assumes that the project uses Autoconf (@pxref{Top, , Introduction,
autoconf, The Autoconf Manual}), and enforces certain restrictions on
the @file{configure.in} contents.

@cindex Automake requirements
@cindex Requirements, Automake

Automake requires @code{perl} in order to generate the
@file{Makefile.in}s.  However, the distributions created by Automake are
fully GNU standards-compliant, and do not require @code{perl} in order
to be built.

@cindex BUGS, reporting
@cindex Reporting BUGS
@cindex E-mail, bug reports

Mail suggestions and bug reports for Automake to
@email{bug-automake@@gnu.org}.


@node Generalities, Examples, Introduction, Top
@chapter General ideas

The following sections cover a few basic ideas that will help you
understand how Automake works.

@menu
* General Operation::           General operation of Automake
* Depth::                       The kinds of packages
* Strictness::                  Standards conformance checking
* Uniform::                     The Uniform Naming Scheme
* Canonicalization::            How derived variables are named
@end menu


@node General Operation, Depth, Generalities, Generalities
@section General Operation

Automake works by reading a @file{Makefile.am} and generating a
@file{Makefile.in}.  Certain macros and targets defined in the
@file{Makefile.am} instruct Automake to generate more specialized code;
for instance, a @samp{bin_PROGRAMS} macro definition will cause targets
for compiling and linking programs to be generated.

@cindex Non-standard targets
@cindex cvs-dist, non-standard example
@trindex cvs-dist

The macro definitions and targets in the @file{Makefile.am} are copied
verbatim into the generated file.  This allows you to add arbitrary code
into the generated @file{Makefile.in}.  For instance the Automake
distribution includes a non-standard @code{cvs-dist} target, which the
Automake maintainer uses to make distributions from his source control
system.

@cindex GNU make extensions

Note that GNU make extensions are not recognized by Automake.  Using
such extensions in a @file{Makefile.am} will lead to errors or confusing
behavior.

Automake tries to group comments with adjoining targets and macro
definitions in an intelligent way.

@cindex Make targets, overriding
@cindex Overriding make targets

A target defined in @file{Makefile.am} generally overrides any such
target of a similar name that would be automatically generated by
@code{automake}.  Although this is a supported feature, it is generally
best to avoid making use of it, as sometimes the generated rules are
very particular.

@cindex Macros, overriding
@cindex Overriding make macros

Similarly, a macro defined in @file{Makefile.am} will override any
definition of the macro that @code{automake} would ordinarily create.
This feature is more often useful than the ability to override a target
definition.  Be warned that many of the macros generated by
@code{automake} are considered to be for internal use only, and their
names might change in future releases.

@cindex Recursive operation of Automake
@cindex Automake, recursive operation
@cindex Example of recursive operation

When examining a macro definition, Automake will recursively examine
macros referenced in the definition.  For example, if Automake is
looking at the content of @code{foo_SOURCES} in this snippet

@example
xs = a.c b.c
foo_SOURCES = c.c $(xs)
@end example

it would use the files @file{a.c}, @file{b.c}, and @file{c.c} as the
contents of @code{foo_SOURCES}.

@cindex ## (special Automake comment)
@cindex Special Automake comment
@cindex Comment, special to Automake

Automake also allows a form of comment which is @emph{not} copied into
the output; all lines beginning with @samp{##} are completely ignored by
Automake.

It is customary to make the first line of @file{Makefile.am} read:

@cindex Makefile.am, first line
@cindex First line of Makefile.am

@example
## Process this file with automake to produce Makefile.in
@end example

@c FIXME discuss putting a copyright into Makefile.am here?  I would but
@c I don't know quite what to say.

@c FIXME document customary ordering of Makefile.am here!


@node Depth, Strictness, General Operation, Generalities
@section Depth

@cindex Flat package
@cindex Package, Flat
@cindex Shallow package
@cindex Package, shallow
@cindex Deep package
@cindex Package, deep

@code{automake} supports three kinds of directory hierarchy:
@samp{flat}, @samp{shallow}, and @samp{deep}.

A @dfn{flat} package is one in which all the files are in a single
directory.  The @file{Makefile.am} for such a package by definition
lacks a @code{SUBDIRS} macro.  An example of such a package is
@code{termutils}.
@vindex SUBDIRS

@cindex SUBDIRS, deep package

A @dfn{deep} package is one in which all the source lies in
subdirectories; the top level directory contains mainly configuration
information.  GNU @code{cpio} is a good example of such a package, as is
GNU @code{tar}.  The top level @file{Makefile.am} for a deep package
will contain a @code{SUBDIRS} macro, but no other macros to define
objects which are built.

A @dfn{shallow} package is one in which the primary source resides in
the top-level directory, while various parts (typically libraries)
reside in subdirectories.  Automake is one such package (as is GNU
@code{make}, which does not currently use @code{automake}).


@node Strictness, Uniform, Depth, Generalities
@section Strictness

@cindex Non-GNU packages

While Automake is intended to be used by maintainers of GNU packages, it
does make some effort to accommodate those who wish to use it, but do
not want to use all the GNU conventions.

@cindex Strictness, defined
@cindex Strictness, foreign
@cindex foreign strictness
@cindex Strictness, gnu
@cindex gnits strictness
@cindex Strictness, gnits
@cindex gnits strictness

To this end, Automake supports three levels of @dfn{strictness}---the
strictness indicating how stringently Automake should check standards
conformance.

The valid strictness levels are:

@table @samp
@item foreign
Automake will check for only those things which are absolutely
required for proper operations.  For instance, whereas GNU standards
dictate the existence of a @file{NEWS} file, it will not be required in
this mode.  The name comes from the fact that Automake is intended to be
used for GNU programs; these relaxed rules are not the standard mode of
operation.

@item gnu
Automake will check---as much as possible---for compliance to the GNU
standards for packages.  This is the default.

@item gnits
Automake will check for compliance to the as-yet-unwritten @dfn{Gnits
standards}.  These are based on the GNU standards, but are even more
detailed.  Unless you are a Gnits standards contributor, it is
recommended that you avoid this option until such time as the Gnits
standard is actually published.
@end table

For more information on the precise implications of the strictness
level, see @ref{Gnits}.


@node Uniform, Canonicalization, Strictness, Generalities
@section The Uniform Naming Scheme

@cindex Uniform naming scheme

Automake macros (from here on referred to as @emph{variables}) generally
follow a @dfn{uniform naming scheme} that makes it easy to decide how
programs (and other derived objects) are built, and how they are
installed.  This scheme also supports @code{configure} time
determination of what should be built.

@cindex _PROGRAMS primary variable
@cindex PROGRAMS primary variable
@cindex Primary variable, PROGRAMS

@cindex Primary variable, defined

At @code{make} time, certain variables are used to determine which
objects are to be built.  These variables are called @dfn{primary
variables}.  For instance, the primary variable @code{PROGRAMS} holds a
list of programs which are to be compiled and linked.
@vindex PROGRAMS

@cindex pkglibdir, defined
@cindex pkgincludedir, defined
@cindex pkgdatadir, defined

@vindex pkglibdir
@vindex pkgincludedir
@vindex pkgdatadir

A different set of variables is used to decide where the built objects
should be installed.  These variables are named after the primary
variables, but have a prefix indicating which standard directory should
be used as the installation directory.  The standard directory names are
given in the GNU standards (@pxref{Directory Variables, , , standards,
The GNU Coding Standards}).  Automake extends this list with
@code{pkglibdir}, @code{pkgincludedir}, and @code{pkgdatadir}; these are
the same as the non-@samp{pkg} versions, but with @samp{@@PACKAGE@@}
appended.  For instance, @code{pkglibdir} is defined as
@code{$(datadir)/@@PACKAGE@@}.
@cvindex PACKAGE

@cindex EXTRA_, prepending

For each primary, there is one additional variable named by prepending
@samp{EXTRA_} to the primary name.  This variable is used to list
objects which may or may not be built, depending on what
@code{configure} decides.  This variable is required because Automake
must statically know the entire list of objects that may be built in
order to generate a @file{Makefile.in} that will work in all cases.

@cindex EXTRA_PROGRAMS, defined
@cindex Example, EXTRA_PROGRAMS
@cindex cpio example

For instance, @code{cpio} decides at configure time which programs are
built.  Some of the programs are installed in @code{bindir}, and some
are installed in @code{sbindir}:

@example
EXTRA_PROGRAMS = mt rmt
bin_PROGRAMS = cpio pax
sbin_PROGRAMS = @@PROGRAMS@@
@end example

Defining a primary variable without a prefix (e.g. @code{PROGRAMS}) is
an error.

Note that the common @samp{dir} suffix is left off when constructing the
variable names; thus one writes @samp{bin_PROGRAMS} and not
@samp{bindir_PROGRAMS}.

Not every sort of object can be installed in every directory.  Automake
will flag those attempts it finds in error.  Automake will also diagnose
obvious misspellings in directory names.

@cindex Extending list of installation directories
@cindex Installation directories, extending list

Sometimes the standard directories---even as augmented by Automake---
are not enough.  In particular it is sometimes useful, for clarity, to
install objects in a subdirectory of some predefined directory.  To this
end, Automake allows you to extend the list of possible installation
directories.  A given prefix (e.g. @samp{zar}) is valid if a variable of
the same name with @samp{dir} appended is defined (e.g. @code{zardir}).

@cindex HTML support, example

For instance, until HTML support is part of Automake, you could use this
to install raw HTML documentation:

@example
htmldir = $(prefix)/html
html_DATA = automake.html
@end example

@cindex noinst primary prefix, definition

The special prefix @samp{noinst} indicates that the objects in question
should not be installed at all.

@cindex check primary prefix, definition

The special prefix @samp{check} indicates that the objects in question
should not be built until the @code{make check} command is run.

Possible primary names are @samp{PROGRAMS}, @samp{LIBRARIES},
@samp{LISP}, @samp{SCRIPTS}, @samp{DATA}, @samp{HEADERS}, @samp{MANS},
and @samp{TEXINFOS}.
@vindex PROGRAMS
@vindex LIBRARIES
@vindex LISP
@vindex SCRIPTS
@vindex DATA
@vindex HEADERS
@vindex MANS
@vindex TEXINFOS


@node Canonicalization,  , Uniform, Generalities
@section How derived variables are named

@cindex canonicalizing Automake macros

Sometimes a Makefile variable name is derived from some text the user
supplies.  For instance, program names are rewritten into Makefile macro
names.  Automake canonicalizes this text, so that it does not have to
follow Makefile macro naming rules.  All characters in the name except
for letters, numbers, and the underscore are turned into underscores
when making macro references.  For example, if your program is named
@code{sniff-glue}, the derived variable name would be
@code{sniff_glue_SOURCES}, not @code{sniff-glue_SOURCES}.


@node Examples, Invoking Automake, Generalities, Top
@chapter Some example packages

@menu
* Complete::                    A simple example, start to finish
* Hello::                       A classic program
* etags::                       Building etags and ctags
@end menu


@node Complete, Hello, Examples, Examples
@section A simple example, start to finish

@cindex Complete example

Let's suppose you just finished writing @code{zardoz}, a program to make
your head float from vortex to vortex.  You've been using Autoconf to
provide a portability framework, but your @file{Makefile.in}s have been
ad-hoc.  You want to make them bulletproof, so you turn to Automake.

@cindex AM_INIT_AUTOMAKE, example use

The first step is to update your @file{configure.in} to include the
commands that @code{automake} needs.  The simplest way to do this is to
add an @code{AM_INIT_AUTOMAKE} call just after @code{AC_INIT}:

@example
AM_INIT_AUTOMAKE(zardoz, 1.0)
@end example

Since your program doesn't have any complicating factors (e.g., it
doesn't use @code{gettext}, it doesn't want to build a shared library),
you're done with this part.  That was easy!

@cindex aclocal program, introduction
@cindex aclocal.m4, preexisting
@cindex acinclude.m4, defined

Now you must regenerate @file{configure}.  But to do that, you'll need
to tell @code{autoconf} how to find the new macro you've used.  The
easiest way to do this is to use the @code{aclocal} program to generate
your @file{aclocal.m4} for you.  But wait... you already have an
@file{aclocal.m4}, because you had to write some hairy macros for your
program.  The @code{aclocal} program lets you put your own macros into
@file{acinclude.m4}, so simply rename and then run:

@example
mv aclocal.m4 acinclude.m4
aclocal
autoconf
@end example

@cindex zardoz example

Now it is time to write your @file{Makefile.am} for @code{zardoz}.
Since @code{zardoz} is a user program, you want to install it where the
rest of the user programs go.  Additionally, @code{zardoz} has some
Texinfo documentation.  Your @file{configure.in} script uses
@code{AC_REPLACE_FUNCS}, so you need to link against @samp{@@LIBOBJS@@}.
So here's what you'd write:

@example
bin_PROGRAMS = zardoz
zardoz_SOURCES = main.c head.c float.c vortex9.c gun.c
zardoz_LDADD = @@LIBOBJS@@

info_TEXINFOS = zardoz.texi
@end example

Now you can run @code{automake --add-missing} to generate your
@file{Makefile.in} and grab any auxiliary files you might need, and
you're done!


@node Hello, etags, Complete, Examples
@section A classic program

@cindex Example, GNU Hello
@cindex Hello example
@cindex GNU Hello, example

@uref{ftp://prep.ai.mit.edu/pub/gnu/hello-1.3.tar.gz, GNU hello} is
renowned for its classic simplicity and versatility.  This section shows
how Automake could be used with the GNU Hello package.  The examples
below are from the latest beta version of GNU Hello, but with all of the
maintainer-only code stripped out, as well as all copyright comments.

Of course, GNU Hello is somewhat more featureful than your traditional
two-liner.  GNU Hello is internationalized, does option processing, and
has a manual and a test suite.  GNU Hello is a deep package.

@cindex configure.in, from GNU Hello
@cindex GNU Hello, configure.in
@cindex Hello, configure.in

Here is the @file{configure.in} from GNU Hello:

@example
dnl Process this file with autoconf to produce a configure script.
AC_INIT(src/hello.c)
AM_INIT_AUTOMAKE(hello, 1.3.11)
AM_CONFIG_HEADER(config.h)

dnl Set of available languages.
ALL_LINGUAS="de fr es ko nl no pl pt sl sv"

dnl Checks for programs.
AC_PROG_CC
AC_ISC_POSIX

dnl Checks for libraries.

dnl Checks for header files.
AC_STDC_HEADERS
AC_HAVE_HEADERS(string.h fcntl.h sys/file.h sys/param.h)

dnl Checks for library functions.
AC_FUNC_ALLOCA

dnl Check for st_blksize in struct stat
AC_ST_BLKSIZE

dnl internationalization macros
AM_GNU_GETTEXT
AC_OUTPUT([Makefile doc/Makefile intl/Makefile po/Makefile.in \
           src/Makefile tests/Makefile tests/hello],
   [chmod +x tests/hello])
@end example

The @samp{AM_} macros are provided by Automake (or the Gettext library);
the rest are standard Autoconf macros.


The top-level @file{Makefile.am}:

@example
EXTRA_DIST = BUGS ChangeLog.O
SUBDIRS = doc intl po src tests
@end example

As you can see, all the work here is really done in subdirectories.

The @file{po} and @file{intl} directories are automatically generated
using @code{gettextize}; they will not be discussed here.

@cindex Texinfo file handling example
@cindex Example, handling Texinfo files

In @file{doc/Makefile.am} we see:

@example
info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi
@end example

This is sufficient to build, install, and distribute the GNU Hello
manual.

@cindex Regression test example
@cindex Example, regression test

Here is @file{tests/Makefile.am}:

@example
TESTS = hello
EXTRA_DIST = hello.in testdata
@end example

The script @file{hello} is generated by @code{configure}, and is the
only test case.  @code{make check} will run this test.

@cindex INCLUDES, example usage

Last we have @file{src/Makefile.am}, where all the real work is done:

@example
bin_PROGRAMS = hello
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h 
hello_LDADD = @@INTLLIBS@@ @@ALLOCA@@
localedir = $(datadir)/locale
INCLUDES = -I../intl -DLOCALEDIR=\"$(localedir)\"
@end example


@node etags,  , Hello, Examples
@section Building etags and ctags

@cindex Example, ctags and etags
@cindex ctags Example
@cindex etags Example

Here is another, trickier example.  It shows how to generate two
programs (@code{ctags} and @code{etags}) from the same source file
(@file{etags.c}).  The difficult part is that each compilation of
@file{etags.c} requires different @code{cpp} flags.

@example
bin_PROGRAMS = etags ctags
ctags_SOURCES =
ctags_LDADD = ctags.o

etags.o: etags.c
        $(COMPILE) -DETAGS_REGEXPS -c etags.c

ctags.o: etags.c
        $(COMPILE) -DCTAGS -o ctags.o -c etags.c
@end example

Note that @code{ctags_SOURCES} is defined to be empty---that way no
implicit value is substituted.  The implicit value, however, is used to
generate @code{etags} from @file{etags.o}.

@code{ctags_LDADD} is used to get @file{ctags.o} into the link line.
@code{ctags_DEPENDENCIES} is generated by Automake.

The above rules won't work if your compiler doesn't accept both
@samp{-c} and @samp{-o}.  The simplest fix for this is to introduce a
bogus dependency (to avoid problems with a parallel @code{make}):

@example
etags.o: etags.c ctags.o
        $(COMPILE) -DETAGS_REGEXPS -c etags.c

ctags.o: etags.c
        $(COMPILE) -DCTAGS -c etags.c && mv etags.o ctags.o
@end example

Also, these explicit rules do not work if the de-ANSI-fication feature
is used (@pxref{ANSI}).  Supporting de-ANSI-fication requires a little
more work:

@example
etags._o: etags._c ctags.o
        $(COMPILE) -DETAGS_REGEXPS -c etags.c

ctags._o: etags._c
        $(COMPILE) -DCTAGS -c etags.c && mv etags._o ctags.o
@end example


@node Invoking Automake, configure, Examples, Top
@chapter Creating a @file{Makefile.in}

@cindex Multiple configure.in files
@cindex Invoking Automake
@cindex Automake, invoking

To create all the @file{Makefile.in}s for a package, run the
@code{automake} program in the top level directory, with no arguments.
@code{automake} will automatically find each appropriate
@file{Makefile.am} (by scanning @file{configure.in}; @pxref{configure})
and generate the corresponding @file{Makefile.in}.  Note that
@code{automake} has a rather simplistic view of what constitutes a
package; it assumes that a package has only one @file{configure.in}, at
the top.  If your package has multiple @file{configure.in}s, then you
must run @code{automake} in each directory holding a
@file{configure.in}.

You can optionally give @code{automake} an argument; @file{.am} is
appended to the argument and the result is used as the name of the input
file.  This feature is generally only used to automatically rebuild an
out-of-date @file{Makefile.in}.  Note that @code{automake} must always
be run from the topmost directory of a project, even if being used to
regenerate the @file{Makefile.in} in some subdirectory.  This is
necessary because @code{automake} must scan @file{configure.in}, and
because @code{automake} uses the knowledge that a @file{Makefile.in} is
in a subdirectory to change its behavior in some cases.

@cindex Automake options
@cindex Options, Automake

@code{automake} accepts the following options:

@cindex Extra files distributed with Automake
@cindex Files distributed with Automake
@cindex config.guess

@table @samp
@item -a
@itemx --add-missing
@opindex -a
@opindex --add-missing
Automake requires certain common files to exist in certain situations;
for instance @file{config.guess} is required if @file{configure.in} runs
@code{AC_CANONICAL_HOST}.  Automake is distributed with several of these
files; this option will cause the missing ones to be automatically added
to the package, whenever possible.  In general if Automake tells you a
file is missing, try using this option.  By default Automake tries to
make a symbolic link pointing to its own copy of the missing file; this
can be changed with @code{--copy}.

@item --amdir=@var{dir}
@opindex --amdir
Look for Automake data files in directory @var{dir} instead of in the
installation directory.  This is typically used for debugging.

@item --build-dir=@var{dir}
@opindex --build-dir
Tell Automake where the build directory is.  This option is used when
including dependencies into a @file{Makefile.in} generated by @code{make
dist}; it should not be used otherwise.