Associated with each program is a collection of variables that 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.
_SOURCESvariable 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 (see Support for Other Languages). Otherwise, the file will be ignored as though it were a header file.
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
nodist_ variants of
_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
AUTOMAKE_OPTIONS (see Options).
_LDADD(see below), then you should list the corresponding source files in the
This variable also supports
nodist_EXTRA_maude_SOURCES would list extra
sources that may need to be built, but should not be distributed.
_ARvariable. This is usually used with C++; some C++ compilers require a special invocation in order to instantiate all the templates that should go into a library. For instance, the SGI C++ compiler likes this variable set like so:
libmaude_a_AR = $(CXX) -ar -o
_LIBADDvariable. For instance, this should be used for objects determined by configure (see A Library).
In the case of libtool libraries,
maude_LIBADD can also refer
to other libtool libraries.
_LDADDvariable. For instance, this should be used for objects determined by configure (see Linking).
_LIBADD are inappropriate for passing
program-specific linker flags (except for -l, -L,
-dlopen and -dlpreopen). Use the
for this purpose.
For instance, if your configure.ac uses
could link your program against the X libraries like so:
maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)
We recommend that you use -l and -L only when
referring to third-party libraries, and give the explicit file names
of any library built by your package. Doing so will ensure that
maude_DEPENDENCIES (see below) is correctly defined by default.
AM_LIBTOOLFLAGSvariable. These options are output before libtool's --mode=mode option, so they should not be mode-specific options (those belong to the compiler or linker flags). See Libtool Flags.
_DEPENDENCIESvariable. Each target depends on the contents of such a variable, but no further interpretation is done.
Since these dependencies are associated to the link rule used to
create the programs they should normally list files used by the link
command. That is *.$(OBJEXT), *.a, or *.la files
for programs; *.lo and *.la files for Libtool libraries;
and *.$(OBJEXT) files for static libraries. In rare cases you
may need to add other kinds of files such as linker scripts, but
listing a source file in
_DEPENDENCIES is wrong. If
some source file needs to be built before all the components of a
program are built, consider using the
_DEPENDENCIES is not supplied, it is computed by Automake.
The automatically-assigned value is the contents of
_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.
_DEPENDENCIES is more likely used to perform conditional
compilation using an
AC_SUBST variable that contains a list of
objects. See Conditional Sources, and Conditional Libtool Sources.
EXTRA_*_DEPENDENCIES variable may be useful for cases where
you merely want to augment the automake-generated
_DEPENDENCIES variable rather than replacing it.
_LINKvariable must hold the name of a command that can be passed all the .o file names and libraries to link against as arguments. Note that the name of the underlying program is not passed to
_LINK; typically one uses ‘$@’:
maude_LINK = $(CCLD) -magic -o $@
_LINK variable is not supplied, it may still be generated
and used by Automake due to the use of per-target link flags such as
_LIBTOOLFLAGS, in cases where
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 Renamed Objects.) The use of per-target compilation flags
with C sources requires that the macro
AM_PROG_CC_C_O be called
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)
See Flag Variables Ordering, for more discussion about the
interaction between user variables, ‘AM_’ shadow variables, and
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.
 There are other, more obscure reasons for this limitation as well.