(automake) Uniform

Info Catalog

(automake) Strictness

(automake) Generalities

(automake) Canonicalization

 
 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
 ( 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, 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 ( 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
 ( Program and Library Variables).
 

Info Catalog

(automake) Strictness

(automake) Generalities

(automake) Canonicalization