Next: Building a library, Up: Building Programs and Libraries [Index]
In a directory containing source that gets built into a program (as
opposed to a library), the ‘PROGRAMS’ primary is used. Programs
can be installed in bindir
, sbindir
, libexecdir
,
pkglibdir
, or not at all.
For instance:
bin_PROGRAMS = hello
In this simple case, the resulting Makefile.in will contain code
to generate a program named hello
. The variable
hello_SOURCES
is used to specify which source files get built
into an executable:
hello_SOURCES = hello.c
This causes hello.c to be compiled into hello.o, and then linked to produce hello.
If ‘prog_SOURCES’ is needed, but not specified, then it defaults to
the single file prog.c. Id est in the example above, the
definition of hello_SOURCES
is actually redundant.
Multiple programs can be built in a single directory. Multiple programs can share a single source file. The source file must be listed in each ‘_SOURCES’ definition.
Header files listed in a ‘_SOURCES’ definition will be ignored. Lex (‘.l’) and yacc (‘.y’) files can also be listed; support for these should work but is still preliminary.
Sometimes it is useful to determine the programs that are to be built at
configure time. For instance, GNU cpio
only builts mt
and
rmt
under special circumstances.
In this case, you must notify Automake
of all the programs that
can possibly be built, but at the same time cause the generated
Makefile.in to use the programs specified by configure
.
This is done by having configure
substitute values into each
‘_PROGRAMS’ definition, while listing all optionally built programs in
EXTRA_PROGRAMS
.
If you need to link against libraries that are not found by
configure
, you can use LDADD
to do so. This variable
actually can be used to add any options to the linker command line.
Sometimes, multiple programs are built in one directory but do not share
the same link-time requirements. In this case, you can use the
‘prog_LDADD’ variable (where PROG is the name of the
program as it appears in some ‘_PROGRAMS’ variable, and usually
written in lowercase) to override the global LDADD
. (If this
variable exists for a given program, then that program is not linked
using LDADD
.)
For instance, in GNU cpio, pax
, cpio
, and mt
are
linked against the library libcpio.a. However, rmt
is
built in the same directory, and has no such link requirement. Also,
mt
and rmt
are only built on certain architectures. Here
is what cpio’s src/Makefile.am looks like (abridged):
bin_PROGRAMS = cpio pax @MT@ libexec_PROGRAMS = @RMT@ EXTRA_PROGRAMS = mt rmt LDADD = ../lib/libcpio.a @INTLLIBS@ rmt_LDADD = cpio_SOURCES = … pax_SOURCES = … mt_SOURCES = … rmt_SOURCES = …
It is also occasionally useful to have a program depend on some other target which is not actually part of that program. This can be done using the ‘prog_DEPENDENCIES’ variable. Each program depends on the contents of such a variable, but no further interpretation is done.
Since program names are rewritten into Makefile macro names, program
names must follow Makefile macro syntax. Sometimes it is useful to have
a program whose name does not follow such rules. In these cases,
Automake canonicalizes the program name. All characters in the name
except for letters, numbers, and the underscore are turned into
underscores when making macro references. Eg, if your program is named
sniff-glue
, you would use sniff_glue_SOURCES
, not
sniff-glue_SOURCES
.
Next: Building a library, Up: Building Programs and Libraries [Index]