[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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 section 17. Changing Automake's Behavior).
This variable also supports `dist_' and `nodist_' prefixes, e.g., `nodist_EXTRA_maude_SOURCES'.
$(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 macro set
like so:
libmaude_a_AR = $(CXX) -ar -o |
configure
. Note that `_LIBADD' is not used for shared
libraries; there you must use `_LDADD'.
configure
.
`_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_LINK = $(CCLD) -magic -o $@ |
When using a per-program 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'.
In compilations with per-program 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) |
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |