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
.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
(see 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
(see Options).
EXTRA_maude_SOURCES
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
$(AR) cru
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
_LIBADD
variable. For instance this should be used for objects determined by
configure
(see A Library).
maude_LDADD
_LDADD
variable. For instance this should be used for objects
determined by configure
(see 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.in
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
maude_DEPENDENCIES
_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
_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
_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 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_DEPENDENCIES
_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_SHORTNAME
maude_SHORTNAME
to m
, then in the above per-program
compilation flag example 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.