automake与makefile.am变量详细解释

http://liaowb1234.blog.163.com/blog/static/77155547201038111815281/

 

 

 

9. Building Programs and Libraries

A large part of Automake's functionality is dedicated to making it easy to build programs and libraries.

 

9.1 Building a program
9.2 Building a library
9.3 Building a Shared Library		Building a Libtool library
9.4 Program and Library Variables		Variables controlling program and library builds
9.5 Special handling for LIBOBJS and ALLOCA
9.6 Variables used when building a program
9.7 Yacc and Lex support
9.8 C++ Support
9.9 Assembly Support
9.10 Fortran 77 Support
9.11 Java Support
9.12 Support for Other Languages
9.13 Automatic de-ANSI-fication
9.14 Automatic dependency tracking
9.15 Support for executable extensions

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1 Building a program

In order to build a program, you need to tell Automake which sources are part of it, and which libraries it should be linked with.

This section also covers conditional compilation of sources or programs. Most of the comments about these also apply to libraries (see section 9.2 Building a library ) and Libtool libraries (see section 9.3 Building a Shared Library ).

 

9.1.1 Defining program sources
9.1.2 Linking the program		Linking with libraries or extra objects
9.1.3 Conditional compilation of sources		Handling conditional sources
9.1.4 Conditional compilation of programs		Building program conditionally

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1.1 Defining program sources

 

In a directory containing source that gets built into a program (as opposed to a library or a script), the `PROGRAMS ' primary is used. Programs can be installed in de>bindirde>, de>sbindirde>, de>libexecdirde>, de>pkglibdirde>, or not at all (`noinst '). They can also be built only for de>make checkde>, in which case the prefix is `check '.

For instance:

 

bin_PROGRAMS = hello

In this simple case, the resulting `Makefile.in ' will contain code to generate a program named de>hellode>.

Associated with each program are several assisting variables which are named after the program. These variables are all optional, and have reasonable defaults. Each variable, its use, and default is spelled out below; we use the "hello" example throughout.

The variable de>hello_SOURCESde> is used to specify which source files get built into an executable:

 

hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h

This causes each mentioned `.c ' file to be compiled into the corresponding `.o '. Then all are linked to produce `hello '.

 

If `hello_SOURCES ' is not specified, then it defaults to the single file `hello.c '; that is, the default is to compile a single C file whose base name is the name of the program itself. (This is a terrible default but we are stuck with it for historical reasons.)

Multiple programs can be built in a single directory. Multiple programs can share a single source file, which must be listed in each `_SOURCES ' definition.

 

Header files listed in a `_SOURCES ' definition will be included in the distribution but otherwise ignored. In case it isn't obvious, you should not include the header file generated by `configure ' in a `_SOURCES ' variable; this file should not be distributed. Lex (`.l ') and Yacc (`.y ') files can also be listed; see 9.7 Yacc and Lex support .

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1.2 Linking the program

If you need to link against libraries that are not found by de>configurede>, you can use de>LDADDde> to do so. This variable is used to specify additional objects or libraries to link with; it is inappropriate for specifying specific linker flags, you should use de>AM_LDFLAGSde> for this purpose.

 

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 de>LDADDde>. If this variable exists for a given program, then that program is not linked using de>LDADDde>.

For instance, in GNU cpio, de>paxde>, de>cpiode> and de>mtde> are linked against the library `libcpio.a '. However, de>rmtde> is built in the same directory, and has no such link requirement. Also, de>mtde> and de>rmtde> 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 = ...

 

`prog _LDADD ' is inappropriate for passing program-specific linker flags (except for `-l ', `-L ', `-dlopen ' and `-dlpreopen '). So, use the `prog _LDFLAGS ' variable for this purpose.

 

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.

If `prog _DEPENDENCIES ' is not supplied, it is computed by Automake. The automatically-assigned value is the contents of `prog _LDADD ', 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 `prog _DEPENDENCIES ' to be generated.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1.3 Conditional compilation of sources

You can't put a configure substitution (e.g., `@FOO@ ') into a `_SOURCES ' variable. The reason for this is a bit hard to explain, but suffice to say that it simply won't work. Automake will give an error if you try to do this.

Fortunately there are two other ways to achieve the same result. One is to use configure substitutions in de>_LDADDde> variables, the other is to use an Automake conditional.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1.3.1 Conditional compilation using de>_LDADDde> substitutions

 

Automake must know all the source files that could possibly go into a program, even if not all the files are built in every circumstance. Any files which are only conditionally built should be listed in the appropriate `EXTRA_ ' variable. For instance, if `hello-linux.c ' or `hello-generic.c ' were conditionally included in de>hellode>, the `Makefile.am ' would contain:

 

bin_PROGRAMS = hello hello_SOURCES = hello-common.c EXTRA_hello_SOURCES = hello-linux.c hello-generic.c hello_LDADD = @HELLO_SYSTEM@ hello_DEPENDENCIES = @HELLO_SYSTEM@

You can then setup the de>@HELLO_SYSTEM@de> substitution from `configure.in ':

 

... case $host in *linux*) HELLO_SYSTEM='hello-linux.$(OBJEXT)' ;; *) HELLO_SYSTEM='hello-generic.$(OBJEXT)' ;; esac AC_SUBST([HELLO_SYSTEM]) ...

In this case, de>HELLO_SYSTEMde> should be replaced by `hello-linux.o ' or `hello-bsd.o ', and added to de>hello_DEPENDENCIESde> and de>hello_LDADDde> in order to be built and linked in.

 

---

[