Next: How derived variables are named, Previous: Strictness, Up: General ideas [Contents][Index]
Automake macros (from here on referred to as 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
(see Directory Variables in The GNU Coding Standards).
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, until HTML support 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 (see Building 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 (see Program and Library Variables).
Next: How derived variables are named, Previous: Strictness, Up: General ideas [Contents][Index]