automake - Online Manual Page Of Unix/Linux

Our Recommended Sites:

File: automake.info, Node: Top, Next: Introduction, Up: (dir)

GNU Automake
************

This manual is for GNU Automake (version 1.9.2, 19 September 2004), a
program which creates GNU standards-compliant Makefiles from template
files.

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software
Foundation; with no Invariant Sections, with the Front-Cover texts
being "A GNU Manual," and with the Back-Cover Texts as in (a)
below. A copy of the license is included in the section entitled
"GNU Free Documentation License."

(a) The FSF's Back-Cover Text is: "You have freedom to copy and
modify this GNU Manual, like GNU software. Copies published by
the Free Software Foundation raise funds for GNU development."

* Menu:

* Introduction:: Automake's purpose
* Generalities:: General ideas
* Examples:: Some example packages
* Invoking Automake:: Creating a Makefile.in
* configure:: Scanning configure.ac or configure.in
* Directories:: Declaring subdirectories
* 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
* Rebuilding:: Automatic rebuilding of Makefile
* Options:: Changing Automake's behavior
* Miscellaneous:: Miscellaneous rules
* Include:: Including extra files in an Automake template.
* Conditionals:: Conditionals
* Gnits:: The effect of `--gnu' and `--gnits'
* Cygnus:: The effect of `--cygnus'
* Not Enough:: When Automake is not Enough
* Distributing:: Distributing the Makefile.in
* API versioning:: About compatibility between Automake versions
* Upgrading:: Upgrading to a Newer Automake Version
* FAQ:: Frequently Asked Questions
* History:: Notes about the history of Automake
* Copying This Manual:: How to make copies of this manual
* Indices:: Indices of variables, macros, and concepts

--- The Detailed Node Listing ---

General ideas

* General Operation:: General operation of Automake
* Strictness:: Standards conformance checking
* Uniform:: The Uniform Naming Scheme
* Canonicalization:: How derived variables are named
* User Variables:: Variables reserved for the user
* Auxiliary Programs:: Programs automake might require

Some example packages

* Complete:: A simple example, start to finish
* Hello:: A classic program
* true:: Building true and false

Scanning `configure.ac'

* Requirements:: Configuration requirements
* Optional:: Other things Automake recognizes
* Invoking aclocal:: Auto-generating aclocal.m4
* aclocal options:: aclocal command line arguments
* Macro search path:: Modifying aclocal's search path
* Macros:: Autoconf macros supplied with Automake
* Extending aclocal:: Writing your own aclocal macros
* Local Macros:: Organizing local macros
* Future of aclocal:: aclocal's scheduled death

Auto-generating aclocal.m4

* aclocal options:: Options supported by aclocal
* Macro search path:: How aclocal finds .m4 files

Autoconf macros supplied with Automake

* Public macros:: Macros that you can use.
* Private macros:: Macros that you should not use.

Directories

* Subdirectories:: Building subdirectories recursively
* Conditional Subdirectories:: Conditionally not building directories
* Alternative:: Subdirectories without recursion
* Subpackages:: Nesting packages

Building Programs and Libraries

* A Program:: Building a program
* A Library:: Building a library
* A Shared Library:: Building a Libtool library
* Program and Library Variables:: Variables controlling program and
library builds
* Default _SOURCES:: Default source files
* LIBOBJS:: Special handling for LIBOBJS and ALLOCA
* Program variables:: Variables used when building a program
* Yacc and Lex:: Yacc and Lex support
* C++ Support:: Compiling C++ sources
* Assembly Support:: Compiling assembly sources
* Fortran 77 Support:: Compiling Fortran 77 sources
* Fortran 9x Support:: Compiling Fortran 9x sources
* Java Support:: Compiling Java sources
* Support for Other Languages:: Compiling other languages
* ANSI:: Automatic de-ANSI-fication
* Dependencies:: Automatic dependency tracking
* EXEEXT:: Support for executable extensions

Building a program

* Program Sources:: Defining program sources
* Linking:: Linking with libraries or extra objects
* Conditional Sources:: Handling conditional sources
* Conditional Programs:: Building program conditionally

Building a Shared Library

* Libtool Concept:: Introducing Libtool
* Libtool Libraries:: Declaring Libtool Libraries
* Conditional Libtool Libraries:: Building Libtool Libraries Conditionally
* Conditional Libtool Sources:: Choosing Library Sources Conditionally
* Libtool Convenience Libraries:: Building Convenience Libtool Libraries
* Libtool Modules:: Building Libtool Modules
* Libtool Flags:: Using _LIBADD and _LDFLAGS
* LTLIBOBJ:: Using $(LTLIBOBJ)
* Libtool Issues:: Common Issues Related to Libtool's Use

Fortran 77 Support

* Preprocessing Fortran 77:: Preprocessing Fortran 77 sources
* Compiling Fortran 77 Files:: Compiling Fortran 77 sources
* Mixing Fortran 77 With C and C++:: Mixing Fortran 77 With C and C++

Mixing Fortran 77 With C and C++

* How the Linker is Chosen:: Automatic linker selection

Fortran 9x Support

* Compiling Fortran 9x Files:: Compiling Fortran 9x sources

Other Derived Objects

* Scripts:: Executable scripts
* Headers:: Header files
* Data:: Architecture-independent data files
* Sources:: Derived sources

Built sources

* Built sources example:: Several ways to handle built sources.

Other GNU Tools

* Emacs Lisp:: Emacs Lisp
* gettext:: Gettext
* Libtool:: Libtool
* Java:: Java
* Python:: Python

Building documentation

* Texinfo:: Texinfo
* Man pages:: Man pages

Miscellaneous Rules

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

When Automake Isn't Enough

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

Frequently Asked Questions about Automake

* CVS:: CVS and generated files
* maintainer-mode:: missing and AM_MAINTAINER_MODE
* wildcards:: Why doesn't Automake support wildcards?
* distcleancheck:: Files left in build directory after distclean
* renamed objects:: Why are object files sometimes renamed?
* Multiple Outputs:: Writing rules for tools with many output files

History of Automake

* Timeline:: The Automake story.
* Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking
* Releases:: Statistics about Automake Releases

Copying This Manual

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

Indices

* Macro and Variable Index:: Index of Autoconf macros and Automake variables
* General Index:: General index

File: automake.info, Node: Introduction, Next: Generalities, Prev: Top, Up: Top

1 Introduction
**************

Automake is a tool for automatically generating `Makefile.in's from
files called `Makefile.am'. Each `Makefile.am' is basically a series
of `make' variable definitions(1), with rules being thrown in
occasionally. The generated `Makefile.in's are compliant with the GNU
Makefile standards.

The GNU Makefile Standards Document (*note Makefile Conventions:
(standards)Makefile Conventions.) 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 variable
definitions. Each such file is processed to create a `Makefile.in'.
There should generally be one `Makefile.am' per directory of a project.

Automake does constrain a project in certain ways; for instance it
assumes that the project uses Autoconf (*note Introduction:
(autoconf)Top.), and enforces certain restrictions on the
`configure.ac' contents(2).

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

Mail suggestions and bug reports for Automake to
<>.

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

(1) These variables are also called "make macros" in Make
terminology, however in this manual we reserve the term "macro" for
Autoconf's macros.

(2) Older Autoconf versions used `configure.in'. Autoconf 2.50 and
greater promotes `configure.ac' over `configure.in'. The rest of this
documentation will refer to `configure.ac', but Automake also supports
`configure.in' for backward compatibility.

File: automake.info, Node: Generalities, Next: Examples, Prev: Introduction, Up: Top

2 General ideas
***************

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

* Menu:

File: automake.info, Node: General Operation, Next: Strictness, Up: Generalities

2.1 General Operation
=====================

Automake works by reading a `Makefile.am' and generating a
`Makefile.in'. Certain variables and rules defined in the
`Makefile.am' instruct Automake to generate more specialized code; for
instance, a `bin_PROGRAMS' variable definition will cause rules for
compiling and linking programs to be generated.

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

Note that most GNU make extensions are not recognized by Automake.
Using such extensions in a `Makefile.am' will lead to errors or
confusing behavior.

A special exception is that the GNU make append operator, `+=', is
supported. This operator appends its right hand argument to the
variable specified on the left. Automake will translate the operator
into an ordinary `=' operator; `+=' will thus work with any make
program.

Automake tries to keep comments grouped with any adjoining rules or
variable definitions.

A rule defined in `Makefile.am' generally overrides any such rule of
a similar name that would be automatically generated by `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.

Similarly, a variable defined in `Makefile.am' or `AC_SUBST''ed from
`configure.ac' will override any definition of the variable that
`automake' would ordinarily create. This feature is more often useful
than the ability to override a rule. Be warned that many of the
variables generated by `automake' are considered to be for internal use
only, and their names might change in future releases.

When examining a variable definition, Automake will recursively
examine variables referenced in the definition. For example, if
Automake is looking at the content of `foo_SOURCES' in this snippet

xs = a.c b.c
foo_SOURCES = c.c $(xs)

it would use the files `a.c', `b.c', and `c.c' as the contents of
`foo_SOURCES'.

Automake also allows a form of comment which is _not_ copied into
the output; all lines beginning with `##' (leading spaces allowed) are
completely ignored by Automake.

It is customary to make the first line of `Makefile.am' read:

## Process this file with automake to produce Makefile.in

File: automake.info, Node: Strictness, Next: Uniform, Prev: General Operation, Up: Generalities

2.2 Strictness
==============

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.

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

The valid strictness levels are:

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

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

`gnits'
Automake will check for compliance to the as-yet-unwritten "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 (which may never happen).

For more information on the precise implications of the strictness
level, see *Note Gnits::.

Automake also has a special "cygnus" mode which is similar to
strictness but handled differently. This mode is useful for packages
which are put into a "Cygnus" style tree (e.g., the GCC tree). For
more information on this mode, see *Note Cygnus::.

File: automake.info, Node: Uniform, Next: Canonicalization, Prev: Strictness, Up: Generalities

2.3 The Uniform Naming Scheme
=============================

Automake variables generally follow a "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
`configure' time determination of what should be built.

At `make' time, certain variables are used to determine which
objects are to be built. The variable names are made of several pieces
which are concatenated together.

The piece which tells automake what is being built is commonly called
the "primary". For instance, the primary `PROGRAMS' holds a list of
programs which are to be compiled and linked.

A different set of names is used to decide where the built objects
should be installed. These names are prefixes to the primary which
indicate which standard directory should be used as the installation
directory. The standard directory names are given in the GNU standards
(*note Directory Variables: (standards)Directory Variables.). Automake
extends this list with `pkglibdir', `pkgincludedir', and `pkgdatadir';
these are the same as the non-`pkg' versions, but with `$(PACKAGE)'
appended. For instance, `pkglibdir' is defined as
`$(libdir)/$(PACKAGE)'.

For each primary, there is one additional variable named by
prepending `EXTRA_' to the primary name. This variable is used to list
objects which may or may not be built, depending on what `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 `Makefile.in' that will work in all cases.

For instance, `cpio' decides at configure time which programs are
built. Some of the programs are installed in `bindir', and some are
installed in `sbindir':

EXTRA_PROGRAMS = mt rmt
bin_PROGRAMS = cpio pax
sbin_PROGRAMS = $(MORE_PROGRAMS)

Defining a primary without a prefix as a variable, e.g., `PROGRAMS',
is an error.

Note that the common `dir' suffix is left off when constructing the
variable names; thus one writes `bin_PROGRAMS' and not
`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.

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. `zar') is valid if a variable of the
same name with `dir' appended is defined (e.g. `zardir').

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

htmldir = $(prefix)/html
html_DATA = automake.html

The special prefix `noinst' indicates that the objects in question
should be built but not installed at all. This is usually used for
objects required to build the rest of your package, for instance static
libraries (*note A Library::), or helper scripts.

The special prefix `check' indicates that the objects in question
should not be built until the `make check' command is run. Those
objects are not installed either.

The current primary names are `PROGRAMS', `LIBRARIES', `LISP',
`PYTHON', `JAVA', `SCRIPTS', `DATA', `HEADERS', `MANS', and `TEXINFOS'.

Some primaries also allow additional prefixes which control other
aspects of `automake''s behavior. The currently defined prefixes are
`dist_', `nodist_', and `nobase_'. These prefixes are explained later
(*note Program and Library Variables::).

File: automake.info, Node: Canonicalization, Next: User Variables, Prev: Uniform, Up: Generalities

2.4 How derived variables are named
===================================

Sometimes a Makefile variable name is derived from some text the
maintainer supplies. For instance, a program name listed in
`_PROGRAMS' is rewritten into the name of a `_SOURCES' variable. In
cases like this, Automake canonicalizes the text, so that program names
and the like do not have to follow Makefile variable naming rules. All
characters in the name except for letters, numbers, the strudel (@),
and the underscore are turned into underscores when making variable
references.

For example, if your program is named `sniff-glue', the derived
variable name would be `sniff_glue_SOURCES', not `sniff-glue_SOURCES'.
Similarly the sources for a library named `libmumble++.a' should be
listed in the `libmumble___a_SOURCES' variable.

The strudel is an addition, to make the use of Autoconf
substitutions in variable names less obfuscating.

File: automake.info, Node: User Variables, Next: Auxiliary Programs, Prev: Canonicalization, Up: Generalities

2.5 Variables reserved for the user
===================================

Some `Makefile' variables are reserved by the GNU Coding Standards for
the use of the "user" - the person building the package. For instance,
`CFLAGS' is one such variable.

Sometimes package developers are tempted to set user variables such
as `CFLAGS' because it appears to make their job easier. However, the
package itself should never set a user variable, particularly not to
include switches which are required for proper compilation of the
package. Since these variables are documented as being for the package
builder, that person rightfully expects to be able to override any of
these variables at build time.

To get around this problem, automake introduces an automake-specific
shadow variable for each user flag variable. (Shadow variables are not
introduced for variables like `CC', where they would make no sense.)
The shadow variable is named by prepending `AM_' to the user variable's
name. For instance, the shadow variable for `YFLAGS' is `AM_YFLAGS'.

File: automake.info, Node: Auxiliary Programs, Prev: User Variables, Up: Generalities

2.6 Programs automake might require
===================================

Automake sometimes requires helper programs so that the generated
`Makefile' can do its work properly. There are a fairly large number
of them, and we list them here.

`ansi2knr.c'
`ansi2knr.1'
These two files are used by the automatic de-ANSI-fication support
(*note ANSI::).

`compile'
This is a wrapper for compilers which don't accept both `-c' and
`-o' at the same time. It is only used when absolutely required.
Such compilers are rare.

`config.guess'
`config.sub'
These programs compute the canonical triplets for the given build,
host, or target architecture. These programs are updated
regularly to support new architectures and fix probes broken by
changes in new kernel versions. You are encouraged to fetch the
latest versions of these files from
`ftp://ftp.gnu.org/gnu/config/' before making a release.

`depcomp'
This program understands how to run a compiler so that it will
generate not only the desired output but also dependency
information which is then used by the automatic dependency
tracking feature.

`elisp-comp'
This program is used to byte-compile Emacs Lisp code.

`install-sh'
This is a replacement for the `install' program which works on
platforms where `install' is unavailable or unusable.

`mdate-sh'
This script is used to generate a `version.texi' file. It examines
a file and prints some date information about it.

`missing'
This wraps a number of programs which are typically only required
by maintainers. If the program in question doesn't exist,
`missing' prints an informative warning and attempts to fix things
so that the build can continue.

`mkinstalldirs'
This script used to be a wrapper around `mkdir -p', which is not
portable. Now we use prefer to use `install-sh -d' when configure
finds that `mkdir -p' does not work, this makes one less script to
distribute.

For backward compatibility `mkinstalldirs' is still used and
distributed when `automake' finds it in a package. But it is no
longer installed automatically, and it should be safe to remove it.

`py-compile'
This is used to byte-compile Python scripts.

`texinfo.tex'
Not a program, this file is required for `make dvi', `make ps' and
`make pdf' to work when Texinfo sources are in the package.

`ylwrap'
This program wraps `lex' and `yacc' and ensures that, for
instance, multiple `yacc' instances can be invoked in a single
directory in parallel.

File: automake.info, Node: Examples, Next: Invoking Automake, Prev: Generalities, Up: Top

3 Some example packages
***********************

* Menu:

* Complete:: A simple example, start to finish
* Hello:: A classic program
* true:: Building true and false

File: automake.info, Node: Complete, Next: Hello, Up: Examples

3.1 A simple example, start to finish
=====================================

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

The first step is to update your `configure.ac' to include the
commands that `automake' needs. The way to do this is to add an
`AM_INIT_AUTOMAKE' call just after `AC_INIT':

AC_INIT(zardoz, 1.0)
AM_INIT_AUTOMAKE
...

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

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

mv aclocal.m4 acinclude.m4
aclocal
autoconf

Now it is time to write your `Makefile.am' for `zardoz'. Since
`zardoz' is a user program, you want to install it where the rest of
the user programs go: `bindir'. Additionally, `zardoz' has some
Texinfo documentation. Your `configure.ac' script uses
`AC_REPLACE_FUNCS', so you need to link against `$(LIBOBJS)'. So
here's what you'd write:

bin_PROGRAMS = zardoz
zardoz_SOURCES = main.c head.c float.c vortex9.c gun.c
zardoz_LDADD = $(LIBOBJS)

info_TEXINFOS = zardoz.texi

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

File: automake.info, Node: Hello, Next: true, Prev: Complete, Up: Examples

3.2 A classic program
=====================

GNU hello (ftp://prep.ai.mit.edu/pub/gnu/hello-1.3.tar.gz) 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.

Here is the `configure.ac' from GNU Hello. *Please note:* The calls
to `AC_INIT' and `AM_INIT_AUTOMAKE' in this example use a deprecated
syntax. For the current approach, see the description of
`AM_INIT_AUTOMAKE' in *Note Public macros::.

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

The `AM_' macros are provided by Automake (or the Gettext library);
the rest are standard Autoconf macros.

The top-level `Makefile.am':

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

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

The `po' and `intl' directories are automatically generated using
`gettextize'; they will not be discussed here.

In `doc/Makefile.am' we see:

info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi

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

Here is `tests/Makefile.am':

TESTS = hello
EXTRA_DIST = hello.in testdata

The script `hello' is generated by `configure', and is the only test
case. `make check' will run this test.

Last we have `src/Makefile.am', where all the real work is done:

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)\"

File: automake.info, Node: true, Prev: Hello, Up: Examples

3.3 Building true and false
===========================

Here is another, trickier example. It shows how to generate two
programs (`true' and `false') from the same source file (`true.c').
The difficult part is that each compilation of `true.c' requires
different `cpp' flags.

bin_PROGRAMS = true false
false_SOURCES =
false_LDADD = false.o

true.o: true.c
$(COMPILE) -DEXIT_CODE=0 -c true.c

false.o: true.c
$(COMPILE) -DEXIT_CODE=1 -o false.o -c true.c

Note that there is no `true_SOURCES' definition. Automake will
implicitly assume that there is a source file named `true.c', and
define rules to compile `true.o' and link `true'. The `true.o: true.c'
rule supplied by the above `Makefile.am', will override the Automake
generated rule to build `true.o'.

`false_SOURCES' is defined to be empty--that way no implicit value
is substituted. Because we have not listed the source of `false', we
have to tell Automake how to link the program. This is the purpose of
the `false_LDADD' line. A `false_DEPENDENCIES' variable, holding the
dependencies of the `false' target will be automatically generated by
Automake from the content of `false_LDADD'.

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

true.o: true.c false.o
$(COMPILE) -DEXIT_CODE=0 -c true.c

false.o: true.c
$(COMPILE) -DEXIT_CODE=1 -c true.c && mv true.o false.o

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

true_.o: true_.c false_.o
$(COMPILE) -DEXIT_CODE=0 -c true_.c

false_.o: true_.c
$(COMPILE) -DEXIT_CODE=1 -c true_.c && mv true_.o false_.o

As it turns out, there is also a much easier way to do this same
task. Some of the above techniques are useful enough that we've kept
the example in the manual. However if you were to build `true' and
`false' in real life, you would probably use per-program compilation
flags, like so:

bin_PROGRAMS = false true

false_SOURCES = true.c
false_CPPFLAGS = -DEXIT_CODE=1

true_SOURCES = true.c
true_CPPFLAGS = -DEXIT_CODE=0

In this case Automake will cause `true.c' to be compiled twice, with
different flags. De-ANSI-fication will work automatically. In this
instance, the names of the object files would be chosen by automake;
they would be `false-true.o' and `true-true.o'. (The name of the
object files rarely matters.)

File: automake.info, Node: Invoking Automake, Next: configure, Prev: Examples, Up: Top

4 Creating a `Makefile.in'
**************************

To create all the `Makefile.in's for a package, run the `automake'
program in the top level directory, with no arguments. `automake' will
automatically find each appropriate `Makefile.am' (by scanning
`configure.ac'; *note configure::) and generate the corresponding
`Makefile.in'. Note that `automake' has a rather simplistic view of
what constitutes a package; it assumes that a package has only one
`configure.ac', at the top. If your package has multiple
`configure.ac's, then you must run `automake' in each directory holding
a `configure.ac'. (Alternatively, you may rely on Autoconf's
`autoreconf', which is able to recurse your package tree and run
`automake' where appropriate.)

You can optionally give `automake' an argument; `.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 `Makefile.in'. Note that `automake' must always be run
from the topmost directory of a project, even if being used to
regenerate the `Makefile.in' in some subdirectory. This is necessary
because `automake' must scan `configure.ac', and because `automake'
uses the knowledge that a `Makefile.in' is in a subdirectory to change
its behavior in some cases.

Automake will run `autoconf' to scan `configure.ac' and its
dependencies (`aclocal.m4'), therefore `autoconf' must be in your
`PATH'. If there is an `AUTOCONF' variable in your environment it will
be used instead of `autoconf', this allows you to select a particular
version of Autoconf. By the way, don't misunderstand this paragraph:
Automake runs `autoconf' to *scan* your `configure.ac', this won't build
`configure' and you still have to run `autoconf' yourself for this
purpose.

`automake' accepts the following options:

`-a'
`--add-missing'
Automake requires certain common files to exist in certain
situations; for instance `config.guess' is required if
`configure.ac' runs `AC_CANONICAL_HOST'. Automake is distributed
with several of these files (*note Auxiliary Programs::); 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 `--copy'.

Many of the potentially-missing files are common scripts whose
location may be specified via the `AC_CONFIG_AUX_DIR' macro.
Therefore, `AC_CONFIG_AUX_DIR''s setting affects whether a file is
considered missing, and where the missing file is added (*note
Optional::).

`--libdir=DIR'
Look for Automake data files in directory DIR instead of in the
installation directory. This is typically used for debugging.

`-c'
`--copy'
When used with `--add-missing', causes installed files to be
copied. The default is to make a symbolic link.

`--cygnus'
Causes the generated `Makefile.in's to follow Cygnus rules, instead
of GNU or Gnits rules. For more information, see *Note Cygnus::.

`-f'
`--force-missing'
When used with `--add-missing', causes standard files to be
reinstalled even if they already exist in the source tree. This
involves removing the file from the source tree before creating
the new symlink (or, with `--copy', copying the new file).

`--foreign'
Set the global strictness to `foreign'. For more information, see
*Note Strictness::.

`--gnits'
Set the global strictness to `gnits'. For more information, see
*Note Gnits::.

`--gnu'
Set the global strictness to `gnu'. For more information, see
*Note Gnits::. This is the default strictness.

`--help'
Print a summary of the command line options and exit.

`-i'
`--ignore-deps'
This disables the dependency tracking feature in generated
`Makefile's; see *Note Dependencies::.

`--include-deps'
This enables the dependency tracking feature. This feature is
enabled by default. This option is provided for historical
reasons only and probably should not be used.

`--no-force'
Ordinarily `automake' creates all `Makefile.in's mentioned in
`configure.ac'. This option causes it to only update those
`Makefile.in's which are out of date with respect to one of their
dependents.

`-o DIR'
`--output-dir=DIR'
Put the generated `Makefile.in' in the directory DIR. Ordinarily
each `Makefile.in' is created in the directory of the
corresponding `Makefile.am'. This option is deprecated and will be
removed in a future release.

`-v'
`--verbose'
Cause Automake to print information about which files are being
read or created.

`--version'
Print the version number of Automake and exit.

`-W CATEGORY'

`--warnings=CATEGORY'
Output warnings falling in CATEGORY. CATEGORY can be one of:
`gnu'
warnings related to the GNU Coding Standards (*note Top:
(standards)Top.).

`obsolete'
obsolete features or constructions

`override'
user redefinitions of Automake rules or variables

`portability'
portability issues (e.g., use of Make features which are
known not portable)

`syntax'
weird syntax, unused variables, typos

`unsupported'
unsupported or incomplete features

`all'
all the warnings

`none'
turn off all the warnings

`error'
treat warnings as errors

A category can be turned off by prefixing its name with `no-'. For
instance `-Wno-syntax' will hide the warnings about unused
variables.

The categories output by default are `syntax' and `unsupported'.
Additionally, `gnu' is enabled in `--gnu' and `--gnits' strictness.

`portability' warnings are currently disabled by default, but they
will be enabled in `--gnu' and `--gnits' strictness in a future
release.

The environment variable `WARNINGS' can contain a comma separated
list of categories to enable. It will be taken into account
before the command-line switches, this way `-Wnone' will also
ignore any warning category enabled by `WARNINGS'. This variable
is also used by other tools like `autoconf'; unknown categories
are ignored for this reason.

File: automake.info, Node: configure, Next: Directories, Prev: Invoking Automake, Up: Top

5 Scanning `configure.ac'
*************************

Automake scans the package's `configure.ac' to determine certain
information about the package. Some `autoconf' macros are required and
some variables must be defined in `configure.ac'. Automake will also
use information from `configure.ac' to further tailor its output.

Automake also supplies some Autoconf macros to make the maintenance
easier. These macros can automatically be put into your `aclocal.m4'
using the `aclocal' program.

* Menu:

File: automake.info, Node: Requirements, Next: Optional, Up: configure

5.1 Configuration requirements
==============================

The one real requirement of Automake is that your `configure.ac' call
`AM_INIT_AUTOMAKE'. This macro does several things which are required
for proper Automake operation (*note Macros::).

Here are the other macros which Automake requires but which are not
run by `AM_INIT_AUTOMAKE':

`AC_CONFIG_FILES'
`AC_OUTPUT'
Automake uses these to determine which files to create (*note
Creating Output Files: (autoconf)Output.). A listed file is
considered to be an Automake generated `Makefile' if there exists
a file with the same name and the `.am' extension appended.
Typically, `AC_CONFIG_FILES([foo/Makefile])' will cause Automake to
generate `foo/Makefile.in' if `foo/Makefile.am' exists.

When using `AC_CONFIG_FILES' with multiple input files, as in
`AC_CONFIG_FILES([Makefile:top.in:Makefile.in:bot.in])', Automake
will generate the first `.in' input file for which a `.am' file
exists. If no such file exists the output file is not considered
to be Automake generated.

Files created by `AC_CONFIG_FILES' are removed by `make distclean'.

File: automake.info, Node: Optional, Next: Invoking aclocal, Prev: Requirements, Up: configure

5.2 Other things Automake recognizes
====================================

Every time Automake is run it calls Autoconf to trace `configure.ac'.
This way it can recognize the use of certain macros and tailor the
generated `Makefile.in' appropriately. Currently recognized macros and
their effects are:

`AC_CONFIG_HEADERS'
Automake will generate rules to rebuild these headers. Older
versions of Automake required the use of `AM_CONFIG_HEADER' (*note
Macros::); this is no longer the case today.

`AC_CONFIG_LINKS'
Automake will generate rules to remove `configure' generated links
on `make distclean' and to distribute named source files as part of
`make dist'.

`AC_CONFIG_AUX_DIR'
Automake will look for various helper scripts, such as
`install-sh', in the directory named in this macro invocation.
(The full list of scripts is: `config.guess', `config.sub',
`depcomp', `elisp-comp', `compile', `install-sh', `ltmain.sh',
`mdate-sh', `missing', `mkinstalldirs', `py-compile',
`texinfo.tex', and `ylwrap'.) Not all scripts are always searched
for; some scripts will only be sought if the generated
`Makefile.in' requires them.

If `AC_CONFIG_AUX_DIR' is not given, the scripts are looked for in
their `standard' locations. For `mdate-sh', `texinfo.tex', and
`ylwrap', the standard location is the source directory
corresponding to the current `Makefile.am'. For the rest, the
standard location is the first one of `.', `..', or `../..'
(relative to the top source directory) that provides any one of
the helper scripts. *Note Finding `configure' Input:
(autoconf)Input.

Required files from `AC_CONFIG_AUX_DIR' are automatically
distributed, even if there is no `Makefile.am' in this directory.

`AC_CANONICAL_BUILD'
`AC_CANONICAL_HOST'
`AC_CANONICAL_TARGET'
Automake will ensure that `config.guess' and `config.sub' exist.
Also, the `Makefile' variables `build_triplet', `host_triplet' and
`target_triplet' are introduced. See *Note Getting the Canonical
System Type: (autoconf)Canonicalizing.

`AC_LIBSOURCE'
`AC_LIBSOURCES'
`AC_LIBOBJ'
Automake will automatically distribute any file listed in
`AC_LIBSOURCE' or `AC_LIBSOURCES'.

Note that the `AC_LIBOBJ' macro calls `AC_LIBSOURCE'. So if an
Autoconf macro is documented to call `AC_LIBOBJ([file])', then
`file.c' will be distributed automatically by Automake. This
encompasses many macros like `AC_FUNC_ALLOCA', `AC_FUNC_MEMCMP',
`AC_REPLACE_FUNCS', and others.

By the way, direct assignments to `LIBOBJS' are no longer
supported. You should always use `AC_LIBOBJ' for this purpose.
*Note `AC_LIBOBJ' vs. `LIBOBJS': (autoconf)AC_LIBOBJ vs LIBOBJS.

`AC_PROG_RANLIB'
This is required if any libraries are built in the package. *Note
Particular Program Checks: (autoconf)Particular Programs.

`AC_PROG_CXX'
This is required if any C++ source is included. *Note Particular
Program Checks: (autoconf)Particular Programs.

`AC_PROG_F77'
This is required if any Fortran 77 source is included. This macro
is distributed with Autoconf version 2.13 and later. *Note
Particular Program Checks: (autoconf)Particular Programs.

`AC_F77_LIBRARY_LDFLAGS'
This is required for programs and shared libraries that are a
mixture of languages that include Fortran 77 (*note Mixing Fortran
77 With C and C++::). *Note Autoconf macros supplied with
Automake: Macros.

`AC_PROG_FC'
This is required if any Fortran 90/95 source is included. This
macro is distributed with Autoconf version 2.58 and later. *Note
Particular Program Checks: (autoconf)Particular Programs.

`AC_PROG_LIBTOOL'
Automake will turn on processing for `libtool' (*note
Introduction: (libtool)Top.).

`AC_PROG_YACC'
If a Yacc source file is seen, then you must either use this macro
or define the variable `YACC' in `configure.ac'. The former is
preferred (*note Particular Program Checks: (autoconf)Particular
Programs.).

`AC_PROG_LEX'
If a Lex source file is seen, then this macro must be used. *Note
Particular Program Checks: (autoconf)Particular Programs.

`AC_SUBST'
The first argument is automatically defined as a variable in each
generated `Makefile.in'. *Note Setting Output Variables:
(autoconf)Setting Output Variables.

If the Autoconf manual says that a macro calls `AC_SUBST' for VAR,
or defines the output variable VAR then VAR will be defined in
each `Makefile.in' generated by Automake. E.g. `AC_PATH_XTRA'
defines `X_CFLAGS' and `X_LIBS', so you can use these variables in
any `Makefile.am' if `AC_PATH_XTRA' is called.

`AM_C_PROTOTYPES'
This is required when using automatic de-ANSI-fication; see *Note
ANSI::.

`AM_GNU_GETTEXT'
This macro is required for packages which use GNU gettext (*note
gettext::). It is distributed with gettext. If Automake sees
this macro it ensures that the package meets some of gettext's
requirements.

`AM_MAINTAINER_MODE'
This macro adds a `--enable-maintainer-mode' option to
`configure'. If this is used, `automake' will cause
`maintainer-only' rules to be turned off by default in the
generated `Makefile.in's. This macro defines the `MAINTAINER_MODE'
conditional, which you can use in your own `Makefile.am'.

`m4_include'
Files included by `configure.ac' using this macro will be detected
by Automake and automatically distributed. They will also appear
as dependencies in `Makefile' rules.

`m4_include' is seldom used by `configure.ac' authors, but can
appear in `aclocal.m4' when `aclocal' detects that some required
macros come from files local to your package (as opposed to macros
installed in a system-wide directory, see *Note Invoking
aclocal::).

File: automake.info, Node: Invoking aclocal, Next: aclocal options, Prev: Optional, Up: configure

5.3 Auto-generating aclocal.m4
==============================

Automake includes a number of Autoconf macros which can be used in your
package (*note Macros::); some of them are actually required by
Automake in certain situations. These macros must be defined in your
`aclocal.m4'; otherwise they will not be seen by `autoconf'.

The `aclocal' program will automatically generate `aclocal.m4' files
based on the contents of `configure.ac'. This provides a convenient
way to get Automake-provided macros, without having to search around.
The `aclocal' mechanism allows other packages to supply their own
macros (*note Extending aclocal::). You can also use it to maintain
your own set of custom macros (*note Local Macros::).

At startup, `aclocal' scans all the `.m4' files it can find, looking
for macro definitions (*note Macro search path::). Then it scans
`configure.ac'. Any mention of one of the macros found in the first
step causes that macro, and any macros it in turn requires, to be put
into `aclocal.m4'.

_Putting_ the file that contains the macro definition into
`aclocal.m4' is usually done by copying the entire text of this file,
including unused macro definitions as well as both `#' and `dnl'
comments. If you want to make a comment which will be completely
ignored by `aclocal', use `##' as the comment leader.

When a file selected by `aclocal' is located in a subdirectory
specified as a relative search path with `aclocal''s `-I' argument,
`aclocal' assumes the file belongs to the package and uses `m4_include'
instead of copying it into `aclocal.m4'. This makes the package
smaller, eases dependency tracking, and cause the file to be
distributed automatically. (*note Local Macros:: for an example.) Any
macro which is found in a system-wide directory, or via an absolute
search path will be copied. So use `-I `pwd`/reldir' instead of `-I
reldir' whenever some relative directory need to be considered outside
the package.

The contents of `acinclude.m4', if this file exists, are also
automatically included in `aclocal.m4'. We recommend against using
`acinclude.m4' in new packages (*note Local Macros::).

While computing `aclocal.m4', `aclocal' runs `autom4te' (*note Using
`Autom4te': (autoconf)Using autom4te.) in order to trace the macros
which are really used, and omit from `aclocal.m4' all macros which are
mentioned but otherwise unexpanded (this can happen when a macro is
called conditionally). `autom4te' is expected to be in the `PATH',
just as `autoconf'. Its location can be overridden using the
`AUTOM4TE' environment variable.

* Menu:

* aclocal options:: Options supported by aclocal
* Macro search path:: How aclocal finds .m4 files

File: automake.info, Node: aclocal options, Next: Macro search path, Prev: Invoking aclocal, Up: configure

5.4 aclocal options
===================

`aclocal' accepts the following options:

`--acdir=DIR'
Look for the macro files in DIR instead of the installation
directory. This is typically used for debugging.

`--help'
Print a summary of the command line options and exit.

`-I DIR'
Add the directory DIR to the list of directories searched for
`.m4' files.

`--force'
Always overwrite the output file. The default is to overwrite the
output file only when really needed, i.e., when its contents
changes or if one of its dependencies is younger.

`--output=FILE'
Cause the output to be put into FILE instead of `aclocal.m4'.

`--print-ac-dir'
Prints the name of the directory which `aclocal' will search to
find third-party `.m4' files. When this option is given, normal
processing is suppressed. This option can be used by a package to
determine where to install a macro file.

`--verbose'
Print the names of the files it examines.

`--version'
Print the version number of Automake and exit.

File: automake.info, Node: Macro search path, Next: Macros, Prev: aclocal options, Up: configure

5.5 Macro search path
=====================

By default, `aclocal' searches for `.m4' files in the following
directories, in this order:

`ACDIR-APIVERSION'
This is where the `.m4' macros distributed with automake itself
are stored. APIVERSION depends on the automake release used; for
automake 1.6.x, APIVERSION = `1.6'.

`ACDIR'
This directory is intended for third party `.m4' files, and is
configured when `automake' itself is built. This is
`@datadir@/aclocal/', which typically expands to
`${prefix}/share/aclocal/'. To find the compiled-in value of
ACDIR, use the `--print-ac-dir' option (*note aclocal options::).

As an example, suppose that automake-1.6.2 was configured with
`--prefix=/usr/local'. Then, the search path would be:

1. `/usr/local/share/aclocal-1.6/'

2. `/usr/local/share/aclocal/'

As explained in (*note aclocal options::), there are several options
that can be used to change or extend this search path.

5.5.1 Modifying the macro search path: `--acdir'
------------------------------------------------

The most obvious option to modify the search path is `--acdir=DIR',
which changes default directory and drops the APIVERSION directory.
For example, if one specifies `--acdir=/opt/private/', then the search
path becomes:

1. `/opt/private/'

Note that this option, `--acdir', is intended for use by the
internal automake test suite only; it is not ordinarily needed by
end-users.

5.5.2 Modifying the macro search path: `-I DIR'
-----------------------------------------------

Any extra directories specified using `-I' options (*note aclocal
options::) are _prepended_ to this search list. Thus, `aclocal -I /foo
-I /bar' results in the following search path:

1. `/foo'

2. `/bar'

3. ACDIR-APIVERSION

4. ACDIR

5.5.3 Modifying the macro search path: `dirlist'
------------------------------------------------

There is a third mechanism for customizing the search path. If a
`dirlist' file exists in ACDIR, then that file is assumed to contain a
list of directories, one per line, to be added to the search list.
These directories are searched _after_ all other directories.

For example, suppose `ACDIR/dirlist' contains the following:

/test1
/test2

and that `aclocal' was called with the `-I /foo -I /bar' options.
Then, the search path would be

1. `/foo'

2. `/bar'

3. ACDIR-APIVERSION

4. ACDIR

5. `/test1'

6. `/test2'

If the `--acdir=DIR' option is used, then `aclocal' will search for
the `dirlist' file in DIR. In the `--acdir=/opt/private/' example
above, `aclocal' would look for `/opt/private/dirlist'. Again,
however, the `--acdir' option is intended for use by the internal
automake test suite only; `--acdir' is not ordinarily needed by
end-users.

`dirlist' is useful in the following situation: suppose that
`automake' version `1.6.2' is installed with $prefix=/usr by the system
vendor. Thus, the default search directories are

1. `/usr/share/aclocal-1.6/'

2. `/usr/share/aclocal/'

However, suppose further that many packages have been manually
installed on the system, with $prefix=/usr/local, as is typical. In
that case, many of these "extra" `.m4' files are in
`/usr/local/share/aclocal'. The only way to force `/usr/bin/aclocal'
to find these "extra" `.m4' files is to always call `aclocal -I
/usr/local/share/aclocal'. This is inconvenient. With `dirlist', one
may create the file

`/usr/share/aclocal/dirlist'

which contains only the single line

`/usr/local/share/aclocal'

Now, the "default" search path on the affected system is

1. `/usr/share/aclocal-1.6/'

2. `/usr/share/aclocal/'

3. `/usr/local/share/aclocal/'

without the need for `-I' options; `-I' options can be reserved for
project-specific needs (`my-source-dir/m4/'), rather than using it to
work around local system-dependent tool installation directories.

Similarly, `dirlist' can be handy if you have installed a local copy
Automake on your account and want `aclocal' to look for macros
installed at other places on the system.

File: automake.info, Node: Macros, Next: Extending aclocal, Prev: Macro search path, Up: configure

5.6 Autoconf macros supplied with Automake
==========================================

Automake ships with several Autoconf macros that you can use from your
`configure.ac'. When you use one of them it will be included by
`aclocal' in `aclocal.m4'.

* Menu:

* Public macros:: Macros that you can use.
* Private macros:: Macros that you should not use.

File: automake.info, Node: Public macros, Next: Private macros, Up: Macros

5.6.1 Public macros
-------------------

`AM_CONFIG_HEADER'
Automake will generate rules to automatically regenerate the config
header. This obsolete macro is a synonym of `AC_CONFIG_HEADERS'
today (*note Optional::).

`AM_ENABLE_MULTILIB'
This is used when a "multilib" library is being built. The first
optional argument is the name of the `Makefile' being generated; it
defaults to `Makefile'. The second option argument is used to find
the top source directory; it defaults to the empty string
(generally this should not be used unless you are familiar with
the internals). *Note Multilibs::.

`AM_C_PROTOTYPES'
Check to see if function prototypes are understood by the
compiler. If so, define `PROTOTYPES' and set the output variables
`U' and `ANSI2KNR' to the empty string. Otherwise, set `U' to `_'
and `ANSI2KNR' to `./ansi2knr'. Automake uses these values to
implement automatic de-ANSI-fication.

`AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL'
If the use of `TIOCGWINSZ' requires `', then define
`GWINSZ_IN_SYS_IOCTL'. Otherwise `TIOCGWINSZ' can be found in
`'.

`AM_INIT_AUTOMAKE([OPTIONS])'
`AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])'
Runs many macros required for proper operation of the generated
Makefiles.

This macro has two forms, the first of which is preferred. In
this form, `AM_INIT_AUTOMAKE' is called with a single argument --
a space-separated list of Automake options which should be applied
to every `Makefile.am' in the tree. The effect is as if each
option were listed in `AUTOMAKE_OPTIONS'.

The second, deprecated, form of `AM_INIT_AUTOMAKE' has two required
arguments: the package and the version number. This form is
obsolete because the PACKAGE and VERSION can be obtained from
Autoconf's `AC_INIT' macro (which itself has an old and a new
form).

If your `configure.ac' has:
AC_INIT(src/foo.c)
AM_INIT_AUTOMAKE(mumble, 1.5)
you can modernize it as follows:
AC_INIT(mumble, 1.5)
AC_CONFIG_SRCDIR(src/foo.c)
AM_INIT_AUTOMAKE

Note that if you're upgrading your `configure.ac' from an earlier
version of Automake, it is not always correct to simply move the
package and version arguments from `AM_INIT_AUTOMAKE' directly to
`AC_INIT', as in the example above. The first argument to
`AC_INIT' should be the name of your package (e.g. `GNU Automake'),
not the tarball name (e.g. `automake') that you used to pass to
`AM_INIT_AUTOMAKE'. Autoconf tries to derive a tarball name from
the package name, which should work for most but not all package
names. (If it doesn't work for yours, you can use the
four-argument form of `AC_INIT' -- supported in Autoconf versions
greater than 2.52g -- to provide the tarball name explicitly).

By default this macro `AC_DEFINE''s `PACKAGE' and `VERSION'. This
can be avoided by passing the `no-define' option, as in:
AM_INIT_AUTOMAKE([gnits 1.5 no-define dist-bzip2])
or by passing a third non-empty argument to the obsolete form.

`AM_PATH_LISPDIR'
Searches for the program `emacs', and, if found, sets the output
variable `lispdir' to the full path to Emacs' site-lisp directory.

Note that this test assumes the `emacs' found to be a version that
supports Emacs Lisp (such as GNU Emacs or XEmacs). Other emacsen
can cause this test to hang (some, like old versions of MicroEmacs,
start up in interactive mode, requiring `C-x C-c' to exit, which
is hardly obvious for a non-emacs user). In most cases, however,
you should be able to use `C-c' to kill the test. In order to
avoid problems, you can set `EMACS' to "no" in the environment, or
use the `--with-lispdir' option to `configure' to explicitly set
the correct path (if you're sure you have an `emacs' that supports
Emacs Lisp.

`AM_PROG_AS'
Use this macro when you have assembly code in your project. This
will choose the assembler for you (by default the C compiler) and
set `CCAS', and will also set `CCASFLAGS' if required.

`AM_PROG_CC_C_O'
This is like `AC_PROG_CC_C_O', but it generates its results in the
manner required by automake. You must use this instead of
`AC_PROG_CC_C_O' when you need this functionality.

`AM_PROG_LEX'
Like `AC_PROG_LEX' (*note Particular Program Checks:
(autoconf)Particular Programs.), but uses the `missing' script on
systems that do not have `lex'. `HP-UX 10' is one such system.

`AM_PROG_GCJ'
This macro finds the `gcj' program or causes an error. It sets
`GCJ' and `GCJFLAGS'. `gcj' is the Java front-end to the GNU
Compiler Collection.

`AM_SYS_POSIX_TERMIOS'
Check to see if POSIX termios headers and functions are available
on the system. If so, set the shell variable
`am_cv_sys_posix_termios' to `yes'. If not, set the variable to
`no'.

`AM_WITH_DMALLOC'
Add support for the dmalloc
(ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz) package. If
the user configures with `--with-dmalloc', then define
`WITH_DMALLOC' and add `-ldmalloc' to `LIBS'.

`AM_WITH_REGEX'
Adds `--with-regex' to the `configure' command line. If specified
(the default), then the `regex' regular expression library is
used, `regex.o' is put into `LIBOBJS', and `WITH_REGEX' is
defined. If `--without-regex' is given, then the `rx' regular
expression library is used, and `rx.o' is put into `LIBOBJS'.

File: automake.info, Node: Private macros, Prev: Public macros, Up: Macros

5.6.2 Private macros
--------------------

The following macros are private macros you should not call directly.
They are called by the other public macros when appropriate. Do not
rely on them, as they might be changed in a future version. Consider
them as implementation details; or better, do not consider them at all:
skip this section!

`_AM_DEPENDENCIES'
`AM_SET_DEPDIR'
`AM_DEP_TRACK'
`AM_OUTPUT_DEPENDENCY_COMMANDS'
These macros are used to implement Automake's automatic dependency
tracking scheme. They are called automatically by automake when
required, and there should be no need to invoke them manually.

`AM_MAKE_INCLUDE'
This macro is used to discover how the user's `make' handles
`include' statements. This macro is automatically invoked when
needed; there should be no need to invoke it manually.

`AM_PROG_INSTALL_STRIP'
This is used to find a version of `install' which can be used to
`strip' a program at installation time. This macro is
automatically included when required.

`AM_SANITY_CHECK'
This checks to make sure that a file created in the build
directory is newer than a file in the source directory. This can
fail on systems where the clock is set incorrectly. This macro is
automatically run from `AM_INIT_AUTOMAKE'.

File: automake.info, Node: Extending aclocal, Next: Local Macros, Prev: Macros, Up: configure

5.7 Writing your own aclocal macros
===================================

The `aclocal' program doesn't have any built-in knowledge of any
macros, so it is easy to extend it with your own macros.

This can be used by libraries which want to supply their own Autoconf
macros for use by other programs. For instance the `gettext' library
supplies a macro `AM_GNU_GETTEXT' which should be used by any package
using `gettext'. When the library is installed, it installs this macro
so that `aclocal' will find it.

A macro file's name should end in `.m4'. Such files should be
installed in `$(datadir)/aclocal'. This is as simple as writing:

aclocaldir = $(datadir)/aclocal
aclocal_DATA = mymacro.m4 myothermacro.m4

A file of macros should be a series of properly quoted `AC_DEFUN''s
(*note Macro Definitions: (autoconf)Macro Definitions.). The `aclocal'
programs also understands `AC_REQUIRE' (*note Prerequisite Macros:
(autoconf)Prerequisite Macros.), so it is safe to put each macro in a
separate file. Each file should have no side effects but macro
definitions. Especially, any call to `AC_PREREQ' should be done inside
the defined macro, not at the beginning of the file.

Starting with Automake 1.8, `aclocal' will warn about all
underquoted calls to `AC_DEFUN'. We realize this will annoy a lot of
people, because `aclocal' was not so strict in the past and many third
party macros are underquoted; and we have to apologize for this
temporary inconvenience. The reason we have to be stricter is that a
future implementation of `aclocal' (*note Future of aclocal::) will
have to temporary include all these third party `.m4' files, maybe
several times, even those which are not actually needed. Doing so
should alleviate many problem of the current implementation, however it
requires a stricter style from the macro authors. Hopefully it is easy
to revise the existing macros. For instance
# bad style
AC_PREREQ(2.57)
AC_DEFUN(AX_FOOBAR,
[AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])
should be rewritten as
AC_DEFUN([AX_FOOBAR],
[AC_PREREQ(2.57)dnl
AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])

Wrapping the `AC_PREREQ' call inside the macro ensures that Autoconf
2.57 will not be required if `AX_FOOBAR' is not actually used. Most
importantly, quoting the first argument of `AC_DEFUN' allows the macro
to be redefined or included twice (otherwise this first argument would
be expansed during the second definition).

If you have been directed here by the `aclocal' diagnostic but are
not the maintainer of the implicated macro, you will want to contact
the maintainer of that macro. Please make sure you have the last
version of the macro and that the problem already hasn't been reported
before doing so: people tend to work faster when they aren't flooded by
mails.

Another situation where `aclocal' is commonly used is to manage
macros which are used locally by the package, *Note Local Macros::.

File: automake.info, Node: Local Macros, Next: Future of aclocal, Prev: Extending aclocal, Up: configure

5.8 Handling Local Macros
=========================

Feature tests offered by Autoconf do not cover all needs. People often
have to supplement existing tests with their own macros, or with
third-party macros.

There are two ways to organize custom macros in a package.

The first possibility (the historical practice) is to list all your
macros in `acinclude.m4'. This file will be included in `aclocal.m4'
when you run `aclocal', and its macro(s) will henceforth be visible to
`autoconf'. However if it contains numerous macros, it will rapidly
become difficult to maintain, and it will be almost impossible to share
macros between packages.

The second possibility, which we do recommend, is to write each macro
in its own file and gather all these files in a directory. This
directory is usually called `m4/'. To build `aclocal.m4', one should
therefore instruct `aclocal' to scan `m4/'. From the command line,
this is done with `aclocal -I m4'. The top-level `Makefile.am' should
also be updated to define

ACLOCAL_AMFLAGS = -I m4

`ACLOCAL_AMFLAGS' contains options to pass to `aclocal' when
`aclocal.m4' is to be rebuilt by `make'. This line is also used by
`autoreconf' (*note Using `autoreconf' to Update `configure' Scripts:
(autoconf)autoreconf Invocation.) to run `aclocal' with suitable
options, or by `autopoint' (*note Invoking the `autopoint' Program:
(gettext)autopoint Invocation.) and `gettextize' (*note Invoking the
`gettextize' Program: (gettext)gettextize Invocation.) to locate the
place where Gettext's macros should be installed. So even if you do
not really care about the rebuild rules, you should define
`ACLOCAL_AMFLAGS'.

When `aclocal -I m4' is run, it will build a `aclocal.m4' that
`m4_include's any file from `m4/' that defines a required macro.
Macros not found locally will still be searched in system-wide
directories, as explained in *Note Macro search path::.

Custom macros should be distributed for the same reason that
`configure.ac' is: so that other people have all the sources of your
package if they want to work on it. Actually, this distribution
happens automatically because all `m4_include'd files are distributed.

However there is no consensus on the distribution of third-party
macros that your package may use. Many libraries install their own
macro in the system-wide `aclocal' directory (*note Extending
aclocal::). For instance Guile ships with a file called `guile.m4'
that contains the macro `GUILE_FLAGS' which can be used to define setup
compiler and linker flags appropriate for using Guile. Using
`GUILE_FLAGS' in `configure.ac' will cause `aclocal' to copy `guile.m4'
into `aclocal.m4', but as `guile.m4' is not part of the project, it
will not be distributed. Technically, that means a user which needs to
rebuild `aclocal.m4' will have to install Guile first. This is
probably OK, if Guile already is a requirement to build the package.
However, if Guile is only an optional feature, or if your package might
run on architectures where Guile cannot be installed, this requirement
will hinder development. An easy solution is to copy such third-party
macros in your local `m4/' directory so they get distributed.

File: automake.info, Node: Future of aclocal, Prev: Local Macros, Up: configure

5.9 The Future of `aclocal'
===========================

`aclocal' is expected to disappear. This feature really should not be
offered by Automake. Automake should focus on generating `Makefile's;
dealing with M4 macros really is Autoconf's job. That some people
install Automake just to use `aclocal', but do not use `automake'
otherwise is an indication of how that feature is misplaced.

The new implementation will probably be done slightly differently.
For instance it could enforce the `m4/'-style layout discussed in *Note
Local Macros::, and take care of copying (and even updating)
third-party macros from `/usr/share/aclocal/' into the local `m4/'
directory.

We have no idea when and how this will happen. This has been
discussed several times in the past, but someone still has to commit
itself to that non-trivial task.

From the user point of view, `aclocal''s removal might turn out to
be painful. There is a simple precaution that you may take to make
that switch more seamless: never call `aclocal' yourself. Keep this
guy under the exclusive control of `autoreconf' and Automake's rebuild
rules. Hopefully you won't need to worry about things breaking, when
`aclocal' disappears, because everything will have been taken care of.
If otherwise you used to call `aclocal' directly yourself or from some
script, you will quickly notice the change.

Many packages come with a script called `bootstrap.sh' or
`autogen.sh', that will just call `aclocal', `libtoolize', `gettextize'
or `autopoint', `autoconf', `autoheader', and `automake' in the right
order. Actually this is precisely what `autoreconf' can do for you.
If your package has such a `bootstrap.sh' or `autogen.sh' script,
consider using `autoreconf'. That should simplify its logic a lot
(less things to maintain, yum!), it's even likely you will not need the
script anymore, and more to the point you will not call `aclocal'
directly anymore.

For the time being, third-party packages should continue to install
public macros into `/usr/share/aclocal/'. If `aclocal' is replaced by
another tool it might make sense to rename the directory, but
supporting `/usr/share/aclocal/' for backward compatibility should be
really easy provided all macros are properly written (*note Extending
aclocal::).

File: automake.info, Node: Directories, Next: Programs, Prev: configure, Up: Top

6 Directories
*************

For simple projects that distributes all files in the same directory it
is enough to have a single `Makefile.am' that builds everything in
place.

In larger projects it is common to organize files in different
directories, in a tree. For instance one directory per program, per
library or per module. The traditional approach is to build these
subdirectory recursively: each directory contains its `Makefile'
(generated from `Makefile.am'), and when `make' is run from the top
level directory it enters each subdirectory in turn to build its
contents.

* Menu:

File: automake.info, Node: Subdirectories, Next: Conditional Subdirectories, Up: Directories

6.1 Recursing subdirectories
============================

In packages with subdirectories, the top level `Makefile.am' must tell
Automake which subdirectories are to be built. This is done via the
`SUBDIRS' variable.

The `SUBDIRS' variable holds a list of subdirectories in which
building of various sorts can occur. The rules for many targets (e.g.
`all') in the generated `Makefile' will run commands both locally and
in all specified subdirectories. Note that the directories listed in
`SUBDIRS' are not required to contain `Makefile.am's; only `Makefile's
(after configuration). This allows inclusion of libraries from
packages which do not use Automake (such as `gettext'; see also *Note
Third-Party Makefiles::).

In packages that use subdirectories, the top-level `Makefile.am' is
often very short. For instance, here is the `Makefile.am' from the GNU
Hello distribution:

EXTRA_DIST = BUGS ChangeLog.O README-alpha
SUBDIRS = doc intl po src tests

When Automake invokes `make' in a subdirectory, it uses the value of
the `MAKE' variable. It passes the value of the variable
`AM_MAKEFLAGS' to the `make' invocation; this can be set in
`Makefile.am' if there are flags you must always pass to `make'.

The directories mentioned in `SUBDIRS' are usually direct children
of the current directory, each subdirectory containing its own
`Makefile.am' with a `SUBDIRS' pointing to deeper subdirectories.
Automake can be used to construct packages of arbitrary depth this way.

By default, Automake generates `Makefiles' which work depth-first in
postfix order: the subdirectories are built before the current
directory. However, it is possible to change this ordering. You can
do this by putting `.' into `SUBDIRS'. For instance, putting `.'
first will cause a `prefix' ordering of directories.

Using

SUBDIRS = lib src . test

will cause `lib/' to be built before `src/', then the current directory
will be built, finally the `test/' directory will be built. It is
customary to arrange test directories to be built after everything else
since they are meant to test what have been constructed.

All `clean' rules are run in reverse order of build rules.

File: automake.info, Node: Conditional Subdirectories, Next: Alternative, Prev: Subdirectories, Up: Directories

6.2 Conditional Subdirectories
==============================

It is possible to define the `SUBDIRS' variable conditionally if, like
in the case of GNU `Inetutils', you want to only build a subset of the
entire package.

To illustrate how this works, let's assume we have two directories
`src/' and `opt/'. `src/' should always be built, but we want to
decide in `./configure' whether `opt/' will be built or not. (For this
example we will assume that `opt/' should be built when the variable
`$want_opt' was set to `yes'.)

Running `make' should thus recurse into `src/' always, and then
maybe in `opt/'.

However `make dist' should always recurse into both `src/' and
`opt/'. Because `opt/' should be distributed even if it is not needed
in the current configuration. This means `opt/Makefile' should be
created _unconditionally_.

There are two ways to setup a project like this. You can use
Automake conditionals (*note Conditionals::) or use Autoconf `AC_SUBST'
variables (*note Setting Output Variables: (autoconf)Setting Output
Variables.). Using Automake conditionals is the preferred solution.
Before we illustrate these two possibility, let's introduce
`DIST_SUBDIRS'.

6.2.1 `SUBDIRS' vs. `DIST_SUBDIRS'
----------------------------------

Automake considers two sets of directories, defined by the variables
`SUBDIRS' and `DIST_SUBDIRS'.

`SUBDIRS' contains the subdirectories of the current directory that
must be built (*note Subdirectories::). It must be defined manually;
Automake will never guess a directory is to be built. As we will see
in the next two sections, it is possible to define it conditionally so
that some directory will be omitted from the build.

`DIST_SUBDIRS' is used in rules that need to recurse in all
directories, even those which have been conditionally left out of the
build. Recall our example where we may not want to build subdirectory
`opt/', but yet we want to distribute it? This is where `DIST_SUBDIRS'
come into play: `opt' may not appear in `SUBDIRS', but it must appear
in `DIST_SUBDIRS'.

Precisely, `DIST_SUBDIRS' is used by `make dist', `make distclean',
and `make maintainer-clean'. All other recursive rules use `SUBDIRS'.

If `SUBDIRS' is defined conditionally using Automake conditionals,
Automake will define `DIST_SUBDIRS' automatically from the possibles
values of `SUBDIRS' in all conditions.

If `SUBDIRS' contains `AC_SUBST' variables, `DIST_SUBDIRS' will not
be defined correctly because Automake does not know the possible values
of these variables. In this case `DIST_SUBDIRS' needs to be defined
manually.

6.2.2 Conditional subdirectories with `AM_CONDITIONAL'
------------------------------------------------------

`configure' should output the `Makefile' for each directory and define
a condition into which `opt/' should be built.

...
AM_CONDITIONAL([COND_OPT], [test "$want_opt" = yes])
AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile])
...

Then `SUBDIRS' can be defined in the top-level `Makefile.am' as
follows.

if COND_OPT
MAYBE_OPT = opt
endif
SUBDIRS = src $(MAYBE_OPT)

As you can see, running `make' will rightly recurse into `src/' and
maybe `opt/'.

As you can't see, running `make dist' will recurse into both `src/'
and `opt/' directories because `make dist', unlike `make all', doesn't
use the `SUBDIRS' variable. It uses the `DIST_SUBDIRS' variable.

In this case Automake will define `DIST_SUBDIRS = src opt'
automatically because it knows that `MAYBE_OPT' can contain `opt' in
some condition.

6.2.3 Conditional Subdirectories with `AC_SUBST'
------------------------------------------------

Another possibility is to define `MAYBE_OPT' from `./configure' using
`AC_SUBST':

...
if test "$want_opt" = yes; then
MAYBE_OPT=opt
else
MAYBE_OPT=
fi
AC_SUBST([MAYBE_OPT])
AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile])
...

In this case the top-level `Makefile.am' should look as follows.

SUBDIRS = src $(MAYBE_OPT)
DIST_SUBDIRS = src opt

The drawback is that since Automake cannot guess what the possible
values of `MAYBE_OPT' are, it is necessary to define `DIST_SUBDIRS'.

6.2.4 Non-configured Subdirectories
-----------------------------------

The semantic of `DIST_SUBDIRS' is often misunderstood by some users
that try to _configure and build_ subdirectories conditionally. Here
by configuring we mean creating the `Makefile' (it might also involve
running a nested `configure' script: this is a costly operation that
explains why people want to do it conditionally, but only the `Makefile'
is relevant to the discussion).

The above examples all assume that every `Makefile' is created, even
in directories that are not going to be built. The simple reason is
that we want `make dist' to distribute even the directories that are
not being built (e.g. platform-dependent code), hence `make dist' must
recurse into the subdirectory, hence this directory must be configured
and appear in `DIST_SUBDIRS'.

Building packages that do not configure every subdirectory is a
tricky business, and we do not recommend it to the novice as it is easy
to produce an incomplete tarball by mistake. We will not discuss this
topic in depth here, yet for the adventurous there are a few rules to
remember.

* `SUBDIRS' should always be a subset of `DIST_SUBDIRS'.

It makes little sense to have a directory in `SUBDIRS' that is not
in `DIST_SUBDIRS'. Think of the former as a way to tell which
directories listed in the latter should be built.

* Any directory listed in `DIST_SUBDIRS' and `SUBDIRS' must be
configured.

I.e., the `Makefile' must exists or the recursive `make' rules
will not be able to process the directory.

* Any configured directory must be listed in `DIST_SUBDIRS'.

So that the cleaning rule remove the generated `Makefile's. It
would be correct to see `DIST_SUBDIRS' as a variable that lists
all the directories that have been configured.

In order to prevent recursion in some non-configured directory you
must therefore ensure that this directory do not appear in
`DIST_SUBDIRS' (and `SUBDIRS'). For instance if you define `SUBDIRS'
conditionally using `AC_SUBST' and do not define `DIST_SUBDIRS'
explicitly, it will be default to `$(SUBDIRS)'; another possibility is
to force `DIST_SUBDIRS = $(SUBDIRS)'.

File: automake.info, Node: Alternative, Next: Subpackages, Prev: Conditional Subdirectories, Up: Directories

6.3 An Alternative Approach to Subdirectories
=============================================

If you've ever read Peter Miller's excellent paper, Recursive Make
Considered Harmful
(http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html), the
preceding sections on the use of subdirectories will probably come as
unwelcome advice. For those who haven't read the paper, Miller's main
thesis is that recursive `make' invocations are both slow and
error-prone.

Automake provides sufficient cross-directory support (1) to enable
you to write a single `Makefile.am' for a complex multi-directory
package.

By default an installable file specified in a subdirectory will have
its directory name stripped before installation. For instance, in this
example, the header file will be installed as `$(includedir)/stdio.h':

include_HEADERS = inc/stdio.h

However, the `nobase_' prefix can be used to circumvent this path
stripping. In this example, the header file will be installed as
`$(includedir)/sys/types.h':

nobase_include_HEADERS = sys/types.h

`nobase_' should be specified first when used in conjunction with
either `dist_' or `nodist_' (*note Dist::). For instance:

nobase_dist_pkgdata_DATA = images/vortex.pgm

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

(1) We believe. This work is new and there are probably warts.
*Note Introduction::, for information on reporting bugs.

File: automake.info, Node: Subpackages, Prev: Alternative, Up: Directories

6.4 Nesting Packages
====================

In the GNU Build System, packages can be nested to arbitrary depth.
This means that a package can embedded other packages with their own
`configure', `Makefile's, etc.

These other packages should just appear as subdirectories of their
parent package. They must be listed in `SUBDIRS' like other ordinary
directories. However the subpackage's `Makefile's should be output by
its own `configure' script, not by the parent's `configure'. This is
achieved using the `AC_CONFIG_SUBDIRS' Autoconf macro (*note
AC_CONFIG_SUBDIRS: (autoconf)Subdirectories.).

Here is an example package for an `arm' program that links with an
`hand' library that is a nested package in subdirectory `hand/'.

`arm''s `configure.ac':

AC_INIT([arm], [1.0])
AC_CONFIG_AUX_DIR([.])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
# Call hand's ./configure script recursively.
AC_CONFIG_SUBDIRS([hand])
AC_OUTPUT

`arm''s `Makefile.am':

# Build the library in the hand subdirectory first.
SUBDIRS = hand

# Include hand's header when compiling this directory.
AM_CPPFLAGS = -I$(srcdir)/hand

bin_PROGRAMS = arm
arm_SOURCES = arm.c
# link with the hand library.
arm_LDADD = hand/libhand.a

Now here is `hand''s `hand/configure.ac':

AC_INIT([hand], [1.2])
AC_CONFIG_AUX_DIR([.])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_PROG_RANLIB
AC_CONFIG_FILES([Makefile])
AC_OUTPUT

and its `hand/Makefile.am':

lib_LIBRARIES = libhand.a
libhand_a_SOURCES = hand.c

When `make dist' is run from the top-level directory it will create
an archive `arm-1.0.tar.gz' that contains the `arm' code as well as the
`hand' subdirectory. This package can be built and installed like any
ordinary package, with the usual `./configure && make && make install'
sequence (the `hand' subpackage will be built and installed by the
process).

When `make dist' is run from the hand directory, it will create a
self-contained `hand-1.2.tar.gz' archive. So although it appears to be
embedded in another package, it can still be used separately.

The purpose of the `AC_CONFIG_AUX_DIR([.])' instruction is to force
Automake and Autoconf into search auxiliary script in the current
directory. For instance this means that there will be two copies of
`install-sh': one in the top-level of the `arm' package, and another
one in the `hand/' subdirectory for the `hand' package.

The historical default is to search these auxiliary scripts in the
immediate parent and grand-parent directories. So if the
`AC_CONFIG_AUX_DIR([.])' line was removed from `hand/configure.ac',
that subpackage would share the auxiliary script of the `arm' package.
This may looks like a gain in size (a few kilobytes), but it is
actually a loss of modularity as the `hand' subpackage is no longer
self-contained (`make dist' in the subdirectory will not work anymore).

Packages that do not use Automake need more work to be integrated
this way. *Note Third-Party Makefiles::.

File: automake.info, Node: Programs, Next: Other objects, Prev: Directories, Up: Top

7 Building Programs and Libraries
*********************************

A large part of Automake's functionality is dedicated to making it easy
to build programs and libraries.

* Menu:

File: automake.info, Node: A Program, Next: A Library, Up: Programs

7.1 Building a program
======================

In order to build a program, you need to tell Automake which sources
are part of it, and which libraries it should be linked with.

This section also covers conditional compilation of sources or
programs. Most of the comments about these also apply to libraries
(*note A Library::) and libtool libraries (*note A Shared Library::).

* Menu:

File: automake.info, Node: Program Sources, Next: Linking, Up: A Program

7.1.1 Defining program sources
------------------------------

In a directory containing source that gets built into a program (as
opposed to a library or a script), the `PROGRAMS' primary is used.
Programs can be installed in `bindir', `sbindir', `libexecdir',
`pkglibdir', or not at all (`noinst'). They can also be built only for
`make check', in which case the prefix is `check'.

For instance:

bin_PROGRAMS = hello

In this simple case, the resulting `Makefile.in' will contain code
to generate a program named `hello'.

Associated with each program are several assisting variables which
are named after the program. These variables are all optional, and have
reasonable defaults. Each variable, its use, and default is spelled out
below; we use the "hello" example throughout.

The variable `hello_SOURCES' is used to specify which source files
get built into an executable:

hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h

This causes each mentioned `.c' file to be compiled into the
corresponding `.o'. Then all are linked to produce `hello'.

If `hello_SOURCES' is not specified, then it defaults to the single
file `hello.c' (*note Default _SOURCES::).

Multiple programs can be built in a single directory. Multiple
programs can share a single source file, which must be listed in each
`_SOURCES' definition.

Header files listed in a `_SOURCES' definition will be included in
the distribution but otherwise ignored. In case it isn't obvious, you
should not include the header file generated by `configure' in a
`_SOURCES' variable; this file should not be distributed. Lex (`.l')
and Yacc (`.y') files can also be listed; see *Note Yacc and Lex::.

File: automake.info, Node: Linking, Next: Conditional Sources, Prev: Program Sources, Up: A Program

7.1.2 Linking the program
-------------------------

If you need to link against libraries that are not found by
`configure', you can use `LDADD' to do so. This variable is used to
specify additional objects or libraries to link with; it is
inappropriate for specifying specific linker flags, you should use
`AM_LDFLAGS' for this purpose.

Sometimes, multiple programs are built in one directory but do not
share the same link-time requirements. In this case, you can use the
`PROG_LDADD' variable (where PROG is the name of the program as it
appears in some `_PROGRAMS' variable, and usually written in lowercase)
to override the global `LDADD'. If this variable exists for a given
program, then that program is not linked using `LDADD'.

For instance, in GNU cpio, `pax', `cpio' and `mt' are linked against
the library `libcpio.a'. However, `rmt' is built in the same
directory, and has no such link requirement. Also, `mt' and `rmt' are
only built on certain architectures. Here is what cpio's
`src/Makefile.am' looks like (abridged):

bin_PROGRAMS = cpio pax $(MT)
libexec_PROGRAMS = $(RMT)
EXTRA_PROGRAMS = mt rmt

LDADD = ../lib/libcpio.a $(INTLLIBS)
rmt_LDADD =

cpio_SOURCES = ...
pax_SOURCES = ...
mt_SOURCES = ...
rmt_SOURCES = ...

`PROG_LDADD' is inappropriate for passing program-specific linker
flags (except for `-l', `-L', `-dlopen' and `-dlpreopen'). So, use the
`PROG_LDFLAGS' variable for this purpose.

It is also occasionally useful to have a program depend on some other
target which is not actually part of that program. This can be done
using the `PROG_DEPENDENCIES' variable. Each program depends on the
contents of such a variable, but no further interpretation is done.

If `PROG_DEPENDENCIES' is not supplied, it is computed by Automake.
The automatically-assigned value is the contents of `PROG_LDADD', with
most configure substitutions, `-l', `-L', `-dlopen' and `-dlpreopen'
options removed. The configure substitutions that are left in are only
`$(LIBOBJS)' and `$(ALLOCA)'; these are left because it is known that
they will not cause an invalid value for `PROG_DEPENDENCIES' to be
generated.

File: automake.info, Node: Conditional Sources, Next: Conditional Programs, Prev: Linking, Up: A Program

7.1.3 Conditional compilation of sources
----------------------------------------

You can't put a configure substitution (e.g., `@FOO@' or `$(FOO)' where
`FOO' is defined via `AC_SUBST') into a `_SOURCES' variable. The
reason for this is a bit hard to explain, but suffice to say that it
simply won't work. Automake will give an error if you try to do this.

Fortunately there are two other ways to achieve the same result.
One is to use configure substitutions in `_LDADD' variables, the other
is to use an Automake conditional.

7.1.3.1 Conditional compilation using `_LDADD' substitutions
............................................................

Automake must know all the source files that could possibly go into a
program, even if not all the files are built in every circumstance. Any
files which are only conditionally built should be listed in the
appropriate `EXTRA_' variable. For instance, if `hello-linux.c' or
`hello-generic.c' were conditionally included in `hello', the
`Makefile.am' would contain:

bin_PROGRAMS = hello
hello_SOURCES = hello-common.c
EXTRA_hello_SOURCES = hello-linux.c hello-generic.c
hello_LDADD = $(HELLO_SYSTEM)
hello_DEPENDENCIES = $(HELLO_SYSTEM)

You can then setup the `$(HELLO_SYSTEM)' substitution from
`configure.ac':

...
case $host in
*linux*) HELLO_SYSTEM='hello-linux.$(OBJEXT)' ;;
*) HELLO_SYSTEM='hello-generic.$(OBJEXT)' ;;
esac
AC_SUBST([HELLO_SYSTEM])
...

In this case, `HELLO_SYSTEM' should be replaced by `hello-linux.o'
or `hello-generic.o', and added to `hello_DEPENDENCIES' and
`hello_LDADD' in order to be built and linked in.

7.1.3.2 Conditional compilation using Automake conditionals
...........................................................

An often simpler way to compile source files conditionally is to use
Automake conditionals. For instance, you could use this `Makefile.am'
construct to build the same `hello' example:

bin_PROGRAMS = hello
if LINUX
hello_SOURCES = hello-linux.c hello-common.c
else
hello_SOURCES = hello-generic.c hello-common.c
endif

In this case, your `configure.ac' should setup the `LINUX'
conditional using `AM_CONDITIONAL' (*note Conditionals::).

When using conditionals like this you don't need to use the `EXTRA_'
variable, because Automake will examine the contents of each variable
to construct the complete list of source files.

If your program uses a lot of files, you will probably prefer a
conditional `+='.

bin_PROGRAMS = hello
hello_SOURCES = hello-common.c
if LINUX
hello_SOURCES += hello-linux.c
else
hello_SOURCES += hello-generic.c
endif

File: automake.info, Node: Conditional Programs, Prev: Conditional Sources, Up: A Program

7.1.4 Conditional compilation of programs
-----------------------------------------

Sometimes it is useful to determine the programs that are to be built
at configure time. For instance, GNU `cpio' only builds `mt' and `rmt'
under special circumstances. The means to achieve conditional
compilation of programs are the same you can use to compile source
files conditionally: substitutions or conditionals.

7.1.4.1 Conditional programs using `configure' substitutions
............................................................

In this case, you must notify Automake of all the programs that can
possibly be built, but at the same time cause the generated
`Makefile.in' to use the programs specified by `configure'. This is
done by having `configure' substitute values into each `_PROGRAMS'
definition, while listing all optionally built programs in
`EXTRA_PROGRAMS'.

bin_PROGRAMS = cpio pax $(MT)
libexec_PROGRAMS = $(RMT)
EXTRA_PROGRAMS = mt rmt

As explained in *Note EXEEXT::, Automake will rewrite
`bin_PROGRAMS', `libexec_PROGRAMS', and `EXTRA_PROGRAMS', appending
`$(EXEEXT)' to each binary. Obviously it cannot rewrite values
obtained at run-time through `configure' substitutions, therefore you
should take care of appending `$(EXEEXT)' yourself, as in
`AC_SUBST([MT], ['mt${EXEEXT}'])'.

7.1.4.2 Conditional programs using Automake conditionals
........................................................

You can also use Automake conditionals (*note Conditionals::) to select
programs to be built. In this case you don't have to worry about
`$(EXEEXT)' or `EXTRA_PROGRAMS'.

bin_PROGRAMS = cpio pax
if WANT_MT
bin_PROGRAMS += mt
endif
if WANT_RMT
libexec_PROGRAMS = rmt
endif

File: automake.info, Node: A Library, Next: A Shared Library, Prev: A Program, Up: Programs

7.2 Building a library
======================

Building a library is much like building a program. In this case, the
name of the primary is `LIBRARIES'. Libraries can be installed in
`libdir' or `pkglibdir'.

*Note A Shared Library::, for information on how to build shared
libraries using libtool and the `LTLIBRARIES' primary.

Each `_LIBRARIES' variable is a list of the libraries to be built.
For instance to create a library named `libcpio.a', but not install it,
you would write:

noinst_LIBRARIES = libcpio.a

The sources that go into a library are determined exactly as they are
for programs, via the `_SOURCES' variables. Note that the library name
is canonicalized (*note Canonicalization::), so the `_SOURCES' variable
corresponding to `liblob.a' is `liblob_a_SOURCES', not
`liblob.a_SOURCES'.

Extra objects can be added to a library using the `LIBRARY_LIBADD'
variable. This should be used for objects determined by `configure'.
Again from `cpio':

libcpio_a_LIBADD = $(LIBOBJS) $(ALLOCA)

In addition, sources for extra objects that will not exist until
configure-time must be added to the `BUILT_SOURCES' variable (*note
Sources::).

Building a static library is done by compiling all object files, then
by invoking `$(AR) $(ARFLAGS)' followed by the name of the library and
the list of objects, and finally by calling `$(RANLIB)' on that
library. You should call `AC_PROG_RANLIB' from your `configure.ac' to
define `RANLIB' (Automake will complain otherwise). `AR' and `ARFLAGS'
default to `ar' and `cru' respectively; you can override these two
variables my setting them in your `Makefile.am', by `AC_SUBST'ing them
from your `configure.ac', or by defining a per-library `maude_AR'
variable (*note Program and Library Variables::).

File: automake.info, Node: A Shared Library, Next: Program and Library Variables, Prev: A Library, Up: Programs

7.3 Building a Shared Library
=============================

Building shared libraries portably is a relatively complex matter. For
this reason, GNU Libtool (*note Introduction: (libtool)Top.) was
created to help build shared libraries in a platform-independent way.

* Menu:

File: automake.info, Node: Libtool Concept, Next: Libtool Libraries, Up: A Shared Library

7.3.1 The Libtool Concept
-------------------------

Libtool abstracts shared and static libraries into a unified concept
henceforth called "libtool libraries". Libtool libraries are files
using the `.la' suffix, and can designate a static library, a shared
library, or maybe both. Their exact nature cannot be determined until
`./configure' is run: not all platforms support all kinds of libraries,
and users can explicitly select which libraries should be built.
(However the package's maintainers can tune the default, *Note The
`AC_PROG_LIBTOOL' macro: (libtool)AC_PROG_LIBTOOL.)

Because object files for shared and static libraries must be compiled
differently, libtool is also used during compilation. Object files
built by libtool are called "libtool objects": these are files using
the `.lo' suffix. Libtool libraries are built from these libtool
objects.

You should not assume anything about the structure of `.la' or `.lo'
files and how libtool constructs them: this is libtool's concern, and
the last thing one wants is to learn about libtool's guts. However the
existence of these files matters, because they are used as targets and
dependencies in `Makefile's rules when building libtool libraries.
There are situations where you may have to refer to these, for instance
when expressing dependencies for building source files conditionally
(*note Conditional Libtool Sources::).

People considering writing a plug-in system, with dynamically loaded
modules, should look into `libltdl': libtool's dlopening library (*note
Using libltdl: (libtool)Using libltdl.). This offers a portable
dlopening facility to load libtool libraries dynamically, and can also
achieve static linking where unavoidable.

Before we discuss how to use libtool with Automake in details, it
should be noted that the libtool manual also has a section about how to
use Automake with libtool (*note Using Automake with Libtool:
(libtool)Using Automake.).

File: automake.info, Node: Libtool Libraries, Next: Conditional Libtool Libraries, Prev: Libtool Concept, Up: A Shared Library

7.3.2 Building Libtool Libraries
--------------------------------

Automake uses libtool to build libraries declared with the
`LTLIBRARIES' primary. Each `_LTLIBRARIES' variable is a list of
libtool libraries to build. For instance, to create a libtool library
named `libgettext.la', and install it in `libdir', write:

lib_LTLIBRARIES = libgettext.la
libgettext_la_SOURCES = gettext.c gettext.h ...

Automake predefines the variable `pkglibdir', so you can use
`pkglib_LTLIBRARIES' to install libraries in `$(libdir)/@PACKAGE@/'.

File: automake.info, Node: Conditional Libtool Libraries, Next: Conditional Libtool Sources, Prev: Libtool Libraries, Up: A Shared Library

7.3.3 Building Libtool Libraries Conditionally
----------------------------------------------

Like conditional programs (*note Conditional Programs::), there are two
main ways to build conditional libraries: using Automake conditionals
or using Autoconf `AC_SUBST'itutions.

The important implementation detail you have to be aware of is that
the place where a library will be installed matters to libtool: it
needs to be indicated _at link-time_ using the `-rpath' option.

For libraries whose destination directory is known when Automake
runs, Automake will automatically supply the appropriate `-rpath'
option to libtool. This is the case for libraries listed explicitly in
some installable `_LTLIBRARIES' variables such as `lib_LTLIBRARIES'.

However, for libraries determined at configure time (and thus
mentioned in `EXTRA_LTLIBRARIES'), Automake does not know the final
installation directory. For such libraries you must add the `-rpath'
option to the appropriate `_LDFLAGS' variable by hand.

The examples below illustrate the differences between these two
methods.

Here is an example where `$(WANTEDLIBS)' is an `AC_SUBST'ed variable
set at `./configure'-time to either `libfoo.la', `libbar.la', both, or
none. Although `$(WANTEDLIBS)' appears in the `lib_LTLIBRARIES',
Automake cannot guess it relates to `libfoo.la' or `libbar.la' by the
time it creates the link rule for these two libraries. Therefore the
`-rpath' argument must be explicitly supplied.

EXTRA_LTLIBRARIES = libfoo.la libbar.la
lib_LTLIBRARIES = $(WANTEDLIBS)
libfoo_la_SOURCES = foo.c ...
libfoo_la_LDFLAGS = -rpath '$(libdir)'
libbar_la_SOURCES = bar.c ...
libbar_la_LDFLAGS = -rpath '$(libdir)'

Here is how the same `Makefile.am' would look using Automake
conditionals named `WANT_LIBFOO' and `WANT_LIBBAR'. Now Automake is
able to compute the `-rpath' setting itself, because it's clear that
both libraries will end up in `$(libdir)' if they are installed.

lib_LTLIBRARIES =
if WANT_LIBFOO
lib_LTLIBRARIES += libfoo.la
endif
if WANT_LIBBAR
lib_LTLIBRARIES += libbar.la
endif
libfoo_la_SOURCES = foo.c ...
libbar_la_SOURCES = bar.c ...

File: automake.info, Node: Conditional Libtool Sources, Next: Libtool Convenience Libraries, Prev: Conditional Libtool Libraries, Up: A Shared Library

7.3.4 Libtool Libraries with Conditional Sources
------------------------------------------------

Conditional compilation of sources in a library can be achieved in the
same way as conditional compilation of sources in a program (*note
Conditional Sources::). The only difference is that `_LIBADD' should
be used instead of `_LDADD' and that it should mention libtool objects
(`.lo' files).

So, to mimic the `hello' example from *Note Conditional Sources::,
we could build a `libhello.la' library using either `hello-linux.c' or
`hello-generic.c' with the following `Makefile.am'.

lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello-common.c
EXTRA_libhello_la_SOURCES = hello-linux.c hello-generic.c
libhello_la_LIBADD = $(HELLO_SYSTEM)
libhello_la_DEPENDENCIES = $(HELLO_SYSTEM)

And make sure `$(HELLO_SYSTEM)' is set to either `hello-linux.lo' or
`hello-generic.lo' in `./configure'.

Or we could simply use an Automake conditional as follows.

lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello-common.c
if LINUX
libhello_la_SOURCES += hello-linux.c
else
libhello_la_SOURCES += hello-generic.c
endif

File: automake.info, Node: Libtool Convenience Libraries, Next: Libtool Modules, Prev: Conditional Libtool Sources, Up: A Shared Library

7.3.5 Libtool Convenience Libraries
-----------------------------------

Sometimes you want to build libtool libraries which should not be
installed. These are called "libtool convenience libraries" and are
typically used to encapsulate many sublibraries, later gathered into
one big installed library.

Libtool convenience libraries are declared by `noinst_LTLIBRARIES',
`check_LTLIBRARIES', or even `EXTRA_LTLIBRARIES'. Unlike installed
libtool libraries they do not need an `-rpath' flag at link time
(actually this is the only difference).

Convenience libraries listed in `noinst_LTLIBRARIES' are always
built. Those listed in `check_LTLIBRARIES' are built only upon `make
check'. Finally, libraries listed in `EXTRA_LTLIBRARIES' are never
built explicitly: Automake outputs rules to build them, but if the
library does not appear as a Makefile dependency anywhere it won't be
built (this is why `EXTRA_LTLIBRARIES' is used for conditional
compilation).

Here is a sample setup merging libtool convenience libraries from
subdirectories into one main `libtop.la' library.

# -- Top-level Makefile.am --
SUBDIRS = sub1 sub2 ...
lib_LTLIBRARIES = libtop.la
libtop_la_SOURCES =
libtop_la_LIBADD = \
sub1/libsub1.la \
sub2/libsub2.la \
...

# -- sub1/Makefile.am --
noinst_LTLIBRARIES = libsub1.la
libsub1_la_SOURCES = ...

# -- sub2/Makefile.am --
# showing nested convenience libraries
SUBDIRS = sub2.1 sub2.2 ...
noinst_LTLIBRARIES = libsub2.la
libsub2_la_SOURCES =
libsub2_la_LIBADD = \
sub21/libsub21.la \
sub22/libsub22.la \
...

File: automake.info, Node: Libtool Modules, Next: Libtool Flags, Prev: Libtool Convenience Libraries, Up: A Shared Library

7.3.6 Libtool Modules
---------------------

These are libtool libraries meant to be dlopened. They are indicated
to libtool by passing `-module' at link-time.

pkglib_LTLIBRARIES = mymodule.la
mymodule_la_SOURCES = doit.c
mymodule_la_LDFLAGS = -module

Ordinarily, Automake requires that a Library's name starts with
`lib'. However, when building a dynamically loadable module you might
wish to use a "nonstandard" name.

If `mymodule_la_SOURCES' is not specified, then it defaults to the
single file `mymodule.c' (*note Default _SOURCES::).

File: automake.info, Node: Libtool Flags, Next: LTLIBOBJ, Prev: Libtool Modules, Up: A Shared Library

7.3.7 _LIBADD and _LDFLAGS
--------------------------

As shown in previous sections, the `LIBRARY_LIBADD' variable should be
used to list extra libtool objects (`.lo' files) or libtool libraries
(`.la') to add to LIBRARY.

The `LIBRARY_LDFLAGS' variable is the place to list additional
libtool flags, such as `-version-info', `-static', and a lot more. See
*Note Using libltdl: (libtool)Link mode.

File: automake.info, Node: LTLIBOBJ, Next: Libtool Issues, Prev: Libtool Flags, Up: A Shared Library

7.3.8 `LTLIBOBJS'
-----------------

Where an ordinary library might include `$(LIBOBJS)', a libtool library
must use `$(LTLIBOBJS)'. This is required because the object files
that libtool operates on do not necessarily end in `.o'.

Nowadays, the computation of `LTLIBOBJS' from `LIBOBJS' is performed
automatically by Autoconf (*note `AC_LIBOBJ' vs. `LIBOBJS':
(autoconf)AC_LIBOBJ vs LIBOBJS.).

File: automake.info, Node: Libtool Issues, Prev: LTLIBOBJ, Up: A Shared Library

7.3.9 Common Issues Related to Libtool's Use
--------------------------------------------

7.3.9.1 `required file `./ltmain.sh' not found'
...............................................

Libtool comes with a tool called `libtoolize' that will install
libtool's supporting files into a package. Running this command will
install `ltmain.sh'. You should execute it before `aclocal' and
`automake'.

People upgrading old packages to newer autotools are likely to face
this issue because older Automake versions used to call `libtoolize'.
Therefore old build scripts do not call `libtoolize'.

Since Automake 1.6, it has been decided that running `libtoolize'
was none of Automake's business. Instead, that functionality has been
moved into the `autoreconf' command (*note Using `autoreconf':
(autoconf)autoreconf Invocation.). If you do not want to remember what
to run and when, just learn the `autoreconf' command. Hopefully,
replacing existing `bootstrap.sh' or `autogen.sh' scripts by a call to
`autoreconf' should also free you from any similar incompatible change
in the future.

7.3.9.2 Objects `created with both libtool and without'
.......................................................

Sometimes, the same source file is used both to build a libtool library
and to build another non-libtool target (be it a program or another
library).

Let's consider the following `Makefile.am'.

bin_PROGRAMS = prog
prog_SOURCES = prog.c foo.c ...

lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c ...

(In this trivial case the issue could be avoided by linking `libfoo.la'
with `prog' instead of listing `foo.c' in `prog_SOURCES'. But let's
assume we really want to keep `prog' and `libfoo.la' separate.)

Technically, it means that we should build `foo.$(OBJEXT)' for
`prog', and `foo.lo' for `libfoo.la'. The problem is that in the
course of creating `foo.lo', libtool may erase (or replace)
`foo.$(OBJEXT)' - and this cannot be avoided.

Therefore, when Automake detects this situation it will complain
with a message such as
object `foo.$(OBJEXT)' created both with libtool and without

A workaround for this issue is to ensure that these two objects get
different basenames. As explained in *Note renamed objects::, this
happens automatically when per-targets flags are used.

bin_PROGRAMS = prog
prog_SOURCES = prog.c foo.c ...
prog_CFLAGS = $(AM_CFLAGS)

lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c ...

Adding `prog_CFLAGS = $(AM_CFLAGS)' is almost a no-op, because when the
`prog_CFLAGS' is defined, it is used instead of `AM_CFLAGS'. However
as a side effect it will cause `prog.c' and `foo.c' to be compiled as
`prog-prog.$(OBJEXT)' and `prog-foo.$(OBJEXT)' which solves the issue.

File: automake.info, Node: Program and Library Variables, Next: Default _SOURCES, Prev: A Shared Library, Up: Programs

7.4 Program and Library Variables
=================================

Associated with each program are a collection of variables which can be
used to modify how that program is built. There is a similar list of
such variables for each library. The canonical name of the program (or
library) is used as a base for naming these variables.

In the list below, we use the name "maude" to refer to the program or
library. In your `Makefile.am' you would replace this with the
canonical name of your program. This list also refers to "maude" as a
program, but in general the same rules apply for both static and dynamic
libraries; the documentation below notes situations where programs and
libraries differ.

`maude_SOURCES'
This variable, if it exists, lists all the source files which are
compiled to build the program. These files are added to the
distribution by default. When building the program, Automake will
cause each source file to be compiled to a single `.o' file (or
`.lo' when using libtool). Normally these object files are named
after the source file, but other factors can change this. If a
file in the `_SOURCES' variable has an unrecognized extension,
Automake will do one of two things with it. If a suffix rule
exists for turning files with the unrecognized extension into `.o'
files, then automake will treat this file as it will any other
source file (*note Support for Other Languages::). Otherwise, the
file will be ignored as though it were a header file.

The prefixes `dist_' and `nodist_' can be used to control whether
files listed in a `_SOURCES' variable are distributed. `dist_' is
redundant, as sources are distributed by default, but it can be
specified for clarity if desired.

It is possible to have both `dist_' and `nodist_' variants of a
given `_SOURCES' variable at once; this lets you easily distribute
some files and not others, for instance:

nodist_maude_SOURCES = nodist.c
dist_maude_SOURCES = dist-me.c

By default the output file (on Unix systems, the `.o' file) will be
put into the current build directory. However, if the option
`subdir-objects' is in effect in the current directory then the
`.o' file will be put into the subdirectory named after the source
file. For instance, with `subdir-objects' enabled,
`sub/dir/file.c' will be compiled to `sub/dir/file.o'. Some
people prefer this mode of operation. You can specify
`subdir-objects' in `AUTOMAKE_OPTIONS' (*note Options::).

`EXTRA_maude_SOURCES'
Automake needs to know the list of files you intend to compile
_statically_. For one thing, this is the only way Automake has of
knowing what sort of language support a given `Makefile.in'
requires. (1) This means that, for example, you can't put a
configure substitution like `@my_sources@' into a `_SOURCES'
variable. If you intend to conditionally compile source files and
use `configure' to substitute the appropriate object names into,
e.g., `_LDADD' (see below), then you should list the corresponding
source files in the `EXTRA_' variable.

This variable also supports `dist_' and `nodist_' prefixes, e.g.,
`nodist_EXTRA_maude_SOURCES'.

`maude_AR'
A static library is created by default by invoking `$(AR)
$(ARFLAGS)' followed by the name of the library and then the
objects being put into the library. You can override this by
setting the `_AR' variable. This is usually used with C++; some
C++ compilers require a special invocation in order to instantiate
all the templates which should go into a library. For instance,
the SGI C++ compiler likes this variable set like so:
libmaude_a_AR = $(CXX) -ar -o

`maude_LIBADD'
Extra objects can be added to a _library_ using the `_LIBADD'
variable. For instance this should be used for objects determined
by `configure' (*note A Library::).

`maude_LDADD'
Extra objects can be added to a _program_ by listing them in the
`_LDADD' variable. For instance this should be used for objects
determined by `configure' (*note Linking::).

`_LDADD' and `_LIBADD' are inappropriate for passing
program-specific linker flags (except for `-l', `-L', `-dlopen'
and `-dlpreopen'). Use the `_LDFLAGS' variable for this purpose.

For instance, if your `configure.ac' uses `AC_PATH_XTRA', you
could link your program against the X libraries like so:

maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)

`maude_LDFLAGS'
This variable is used to pass extra flags to the link step of a
program or a shared library.

`maude_DEPENDENCIES'
It is also occasionally useful to have a program depend on some
other target which is not actually part of that program. This can
be done using the `_DEPENDENCIES' variable. Each program depends
on the contents of such a variable, but no further interpretation
is done.

If `_DEPENDENCIES' is not supplied, it is computed by Automake.
The automatically-assigned value is the contents of `_LDADD' or
`_LIBADD', with most configure substitutions, `-l', `-L',
`-dlopen' and `-dlpreopen' options removed. The configure
substitutions that are left in are only `$(LIBOBJS)' and
`$(ALLOCA)'; these are left because it is known that they will not
cause an invalid value for `_DEPENDENCIES' to be generated.

`maude_LINK'
You can override the linker on a per-program basis. By default the
linker is chosen according to the languages used by the program.
For instance, a program that includes C++ source code would use
the C++ compiler to link. The `_LINK' variable must hold the name
of a command which can be passed all the `.o' file names as
arguments. Note that the name of the underlying program is _not_
passed to `_LINK'; typically one uses `$@':

maude_LINK = $(CCLD) -magic -o $@

`maude_CCASFLAGS'
`maude_CFLAGS'
`maude_CPPFLAGS'
`maude_CXXFLAGS'
`maude_FFLAGS'
`maude_GCJFLAGS'
`maude_LFLAGS'
`maude_OBJCFLAGS'
`maude_RFLAGS'
`maude_YFLAGS'
Automake allows you to set compilation flags on a per-program (or
per-library) basis. A single source file can be included in
several programs, and it will potentially be compiled with
different flags for each program. This works for any language
directly supported by Automake. These "per-target compilation
flags" are `_CCASFLAGS', `_CFLAGS', `_CPPFLAGS', `_CXXFLAGS',
`_FFLAGS', `_GCJFLAGS', `_LFLAGS', `_OBJCFLAGS', `_RFLAGS', and
`_YFLAGS'.

When using a per-target compilation flag, Automake will choose a
different name for the intermediate object files. Ordinarily a
file like `sample.c' will be compiled to produce `sample.o'.
However, if the program's `_CFLAGS' variable is set, then the
object file will be named, for instance, `maude-sample.o'. (See
also *Note renamed objects::.)

In compilations with per-target flags, the ordinary `AM_' form of
the flags variable is _not_ automatically included in the
compilation (however, the user form of the variable _is_ included).
So for instance, if you want the hypothetical `maude' compilations
to also use the value of `AM_CFLAGS', you would need to write:

maude_CFLAGS = ... your flags ... $(AM_CFLAGS)

`maude_SHORTNAME'
On some platforms the allowable file names are very short. In
order to support these systems and per-target compilation flags at
the same time, Automake allows you to set a "short name" which
will influence how intermediate object files are named. For
instance, in the following example,

bin_PROGRAMS = maude
maude_CPPFLAGS = -DSOMEFLAG
maude_SHORTNAME = m
maude_SOURCES = sample.c ...

the object file would be named `m-sample.o' rather than
`maude-sample.o'.

This facility is rarely needed in practice, and we recommend
avoiding it until you find it is required.

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

(1) There are other, more obscure reasons for this limitation as
well.

File: automake.info, Node: Default _SOURCES, Next: LIBOBJS, Prev: Program and Library Variables, Up: Programs

7.5 Default `_SOURCES'
======================

`_SOURCES' variables are used to specify source files of programs
(*note A Program::), libraries (*note A Library::), and Libtool
libraries (*note A Shared Library::).

When no such variable is specified for a target, Automake will define
one itself. The default is to compile a single C file whose base name
is the name of the target itself, with any extension replaced by `.c'.
(Defaulting to C is terrible but we are stuck with it for historical
reasons.)

For example if you have the following somewhere in your
`Makefile.am' with no corresponding `libfoo_a_SOURCES':

lib_LIBRARIES = libfoo.a sub/libc++.a

`libfoo.a' will be built using a default source file named `libfoo.c',
and `sub/libc++.a' will be built from `sub/libc++.c'. (In older
versions `sub/libc++.a' would be built from `sub_libc___a.c', i.e., the
default source was the canonized name of the target, with `.c' appended.
We believe the new behavior is more sensible, but for backward
compatibility automake will use the old name if a file or a rule with
that name exist.)

Default sources are mainly useful in test suites, when building many
tests programs each from a single source. For instance in

check_PROGRAMS = test1 test2 test3

`test1', `test2', and `test3' will be built from `test1.c', `test2.c',
and `test3.c'.

Another case where is this convenient is building many Libtool
modules (`moduleN.la'), each defined in its own file (`moduleN.c').

AM_LDFLAGS = -module
lib_LTLIBRARIES = module1.la module2.la module3.la

Finally, there is one situation where this default source computation
needs to be avoided: when a target should not be built from sources.
We already saw such an example in *Note true::; this happens when all
the constituents of a target have already been compiled and need just
to be combined using a `_LDADD' variable. Then it is necessary to
define an empty `_SOURCES' variable, so that automake does not compute
a default.

bin_PROGRAMS = target
target_SOURCES =
target_LDADD = libmain.a libmisc.a

File: automake.info, Node: LIBOBJS, Next: Program variables, Prev: Default _SOURCES, Up: Programs

7.6 Special handling for LIBOBJS and ALLOCA
===========================================

Automake explicitly recognizes the use of `$(LIBOBJS)' and `$(ALLOCA)',
and uses this information, plus the list of `LIBOBJS' files derived
from `configure.ac' to automatically include the appropriate source
files in the distribution (*note Dist::). These source files are also
automatically handled in the dependency-tracking scheme; see *Note
Dependencies::.

`$(LIBOBJS)' and `$(ALLOCA)' are specially recognized in any
`_LDADD' or `_LIBADD' variable.

File: automake.info, Node: Program variables, Next: Yacc and Lex, Prev: LIBOBJS, Up: Programs

7.7 Variables used when building a program
==========================================

Occasionally it is useful to know which `Makefile' variables Automake
uses for compilations; for instance you might need to do your own
compilation in some special cases.

Some variables are inherited from Autoconf; these are `CC',
`CFLAGS', `CPPFLAGS', `DEFS', `LDFLAGS', and `LIBS'.

There are some additional variables which Automake itself defines:

`AM_CPPFLAGS'
The contents of this variable are passed to every compilation
which invokes the C preprocessor; it is a list of arguments to the
preprocessor. For instance, `-I' and `-D' options should be
listed here.

Automake already provides some `-I' options automatically. In
particular it generates `-I$(srcdir)', `-I.', and a `-I' pointing
to the directory holding `config.h' (if you've used
`AC_CONFIG_HEADERS' or `AM_CONFIG_HEADER'). You can disable the
default `-I' options using the `nostdinc' option.

`AM_CPPFLAGS' is ignored in preference to a per-executable (or
per-library) `_CPPFLAGS' variable if it is defined.

`INCLUDES'
This does the same job as `AM_CPPFLAGS' (or any per-target
`_CPPFLAGS' variable if it is used). It is an older name for the
same functionality. This variable is deprecated; we suggest using
`AM_CPPFLAGS' and per-target `_CPPFLAGS' instead.

`AM_CFLAGS'
This is the variable which the `Makefile.am' author can use to pass
in additional C compiler flags. It is more fully documented
elsewhere. In some situations, this is not used, in preference to
the per-executable (or per-library) `_CFLAGS'.

`COMPILE'
This is the command used to actually compile a C source