Next: , Up: Building Programs and Libraries   [Index]


6.1 Building a program

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]