Back: The easy primaries
Forward: Frequently Asked Questions
 
FastBack: Frequently Asked Questions
Up: Introducing GNU Automake
FastForward: Bootstrapping
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

7.4 Programs and libraries

The preceding primaries have all been relatively easy to use. Now we'll discuss a more complicated set, namely those used to build programs and libraries. These primaries are more complex because building a program is more complex than building a script (which often doesn't even need building at all).

Use the PROGRAMS primary for programs, LIBRARIES for libraries, and LTLIBRARIES for Libtool libraries (see section 10. Introducing GNU Libtool). Here is a minimal example:

 
bin_PROGRAMS = doit

This creates the program doit and arranges to install it in bindir. First make will compile `doit.c' to produce `doit.o'. Then it will link `doit.o' to create `doit'.

Of course, if you have more than one source file, and most programs do, then you will want to be able to list them somehow. You will do this via the program's SOURCES variable. Each program or library has a set of associated variables whose names are constructed by appending suffixes to the `normalized' name of the program. The normalized name is the name of the object with non-alphanumeric characters changed to underscores. For instance, the normalized name of `quux' is `quux', but the normalized name of `install-info' is `install_info'. Normalized names are used because they correspond to make syntax, and, like all macros, Automake propagates these definitions into the resulting `Makefile.in'.

So if `doit' is to be built from files `main.c' and `doit.c', we would write:

 
bin_PROGRAMS = doit
doit_SOURCES = doit.c main.c

The same holds for libraries. In the zlib package we might make a library called `libzlib.a'. Then we would write:

 
lib_LIBRARIES = libzlib.a
libzlib_a_SOURCES = adler32.c compress.c crc32.c deflate.c deflate.h \
gzio.c infblock.c infblock.h infcodes.c infcodes.h inffast.c inffast.h \
inffixed.h inflate.c inftrees.c inftrees.h infutil.c infutil.h trees.c \
trees.h uncompr.c zconf.h zlib.h zutil.c zutil.h

We can also do this with libtool libraries. For instance, suppose we want to build `libzlib.la' instead:

 
lib_LTLIBRARIES = libzlib.la
libzlib_la_SOURCES = adler32.c compress.c crc32.c deflate.c deflate.h \
gzio.c infblock.c infblock.h infcodes.c infcodes.h inffast.c inffast.h \
inffixed.h inflate.c inftrees.c inftrees.h infutil.c infutil.h trees.c \
trees.h uncompr.c zconf.h zlib.h zutil.c zutil.h

As you can see, making shared libraries with Automake and Libtool is just as easy as making static libraries.

In the above example, we listed header files in the SOURCES variable. These are ignored (except by make dist (1)) but can serve to make your `Makefile.am' a bit clearer (and sometimes shorter, if you aren't installing headers).

Note that you can't use `configure' substitutions in a SOURCES variable. Automake needs to know the static list of files which can be compiled into your program. There are still various ways to conditionally compile files, for instance Automake conditionals or the use of the LDADD variable.

The static list of files is also used in some versions of Automake's automatic dependency tracking. The general rule is that each source file which might be compiled should be listed in some SOURCES variable. If the source is conditionally compiled, it can be listed in an EXTRA variable. For instance, suppose in this example `@FOO_OBJ@' is conditionally set by `configure' to `foo.o' when `foo.c' should be compiled:

 
bin_PROGRAMS = foo
foo_SOURCES = main.c
foo_LDADD = @FOO_OBJ@
foo_DEPENDENCIES = @FOO_OBJ@
EXTRA_foo_SOURCES = foo.c

In this case, `EXTRA_foo_SOURCES' is used to list sources which are conditionally compiled; this tells Automake that they exist even though it can't deduce their existence automatically.

In the above example, note the use of the `foo_LDADD' macro. This macro is used to list other object files and libraries which should be linked into the foo program. Each program or library has several such associated macros which can be used to customize the link step; here we list the most common ones:

`_DEPENDENCIES'
Extra dependencies which are added to the program's dependency list. If not specified, this is automatically computed based on the value of the program's `_LDADD' macro.

`_LDADD'
Extra objects which are passed to the linker. This is only used by programs and shared libraries.

`_LDFLAGS'
Flags which are passed to the linker. This is separate from `_LDADD' to allow `_DEPENDENCIES' to be auto-computed.

`_LIBADD'
Like `_LDADD', but used for static libraries and not programs.

You aren't required to define any of these macros.


This document was generated by Joost van Baal on August, 23 2005 using texi2html