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.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1.3.2 Conditional compilation using Automake conditionals

An often simpler way to compile source files conditionally is to use Automake conditionals. For instance, you could use this `Makefile.am ' construct to build the same `hello ' example:

 

bin_PROGRAMS = hello if LINUX hello_SOURCES = hello-linux.c hello-common.c else hello_SOURCES = hello-generic.c hello-common.c endif

In this case, your `configure.in ' should setup the de>LINUXde> conditional using de>AM_CONDITIONALde> (see section 20. Conditionals ).

When using conditionals like this you don't need to use the `EXTRA_ ' variable, because Automake will examine the contents of each variable to construct the complete list of source files.

If your program uses a lot of files, you will probably prefer a conditional de>+=de>.

 

bin_PROGRAMS = hello hello_SOURCES = hello-common.c if LINUX hello_SOURCES += hello-linux.c else hello_SOURCES += hello-generic.c endif

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.1.4 Conditional compilation of programs

Sometimes it is useful to determine the programs that are to be built at configure time. For instance, GNU de>cpiode> only builds de>mtde> and de>rmtde> 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 de>configurede>. This is done by having de>configurede> substitute values into each `_PROGRAMS ' definition, while listing all optionally built programs in de>EXTRA_PROGRAMSde>.

Of course you can use Automake conditionals to determine the programs to be built.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.2 Building a library

 

 

Building a library is much like building a program. In this case, the name of the primary is `LIBRARIES '. Libraries can be installed in de>libdirde> or de>pkglibdirde>.

See section 9.3 Building a Shared Library , for information on how to build shared libraries using Libtool and the `LTLIBRARIES ' primary.

Each `_LIBRARIES ' variable is a list of the libraries to be built. For instance to create a library named `libcpio.a ', but not install it, you would write:

 

noinst_LIBRARIES = libcpio.a

The sources that go into a library are determined exactly as they are for programs, via the `_SOURCES ' variables. Note that the library name is canonicalized (see section 2.4 How derived variables are named ), so the `_SOURCES ' variable corresponding to `liblob.a ' is `liblob_a_SOURCES ', not `liblob.a_SOURCES '.

 

Extra objects can be added to a library using the `library _LIBADD ' variable. This should be used for objects determined by de>configurede>. Again from de>cpiode>:

 

libcpio_a_LIBADD = @LIBOBJS@ @ALLOCA@

In addition, sources for extra objects that will not exist until configure-time must be added to the de>BUILT_SOURCESde> variable (see section 10.4 Built sources ).

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.3 Building a Shared Library

 

Building shared libraries is a relatively complex matter. For this reason, GNU Libtool (see section `Introduction' in te>The Libtool Manualte>) was created to help build shared libraries in a platform-independent way.

 

 

Automake uses Libtool to build libraries declared with the `LTLIBRARIES ' primary. Each `_LTLIBRARIES ' variable is a list of shared libraries to build. For instance, to create a library named `libgettext.a ' and its corresponding shared libraries, and install them in `libdir ', write:

 

lib_LTLIBRARIES = libgettext.la

 

 

Note that shared libraries must be installed in order to work properly, so de>check_LTLIBRARIESde> is not allowed. However, de>noinst_LTLIBRARIESde> is allowed. This feature should be used for libtool "convenience libraries".

 

For each library, the `library _LIBADD ' variable contains the names of extra libtool objects (`.lo ' files) to add to the shared library. The `library _LDFLAGS ' variable contains any additional libtool flags, such as `-version-info ' or `-static '.

 

Where an ordinary library might include de>@LIBOBJS@de>, a libtool library must use de>@LTLIBOBJS@de>. This is required because the object files that libtool operates on do not necessarily end in `.o '. The libtool manual contains more details on this topic.

For libraries installed in some directory, Automake will automatically supply the appropriate `-rpath ' option. However, for libraries determined at configure time (and thus mentioned in de>EXTRA_LTLIBRARIESde>), Automake does not know the eventual installation directory; for such libraries you must add the `-rpath ' option to the appropriate `_LDFLAGS ' variable by hand.

Ordinarily, Automake requires that a shared library's name start with `lib '. However, if you are building a dynamically loadable module then you might wish to use a "nonstandard" name. In this case, put de>-modulede> into the `_LDFLAGS ' variable.

See section `The Libtool Manual' in te>The Libtool Manualte>, for more information.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.4 Program and Library Variables

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.

 

` maude_SOURCES '

This variable, if it exists, lists all the source files which are compiled to build the program. These files are added to the distribution by default. When building the program, Automake will cause each source file to be compiled to a single ` .o ' file (or ` .lo ' when using libtool). Normally these object files are named after the source file, but other factors can change this. If a file in the ` _SOURCES ' variable has an unrecognized extension, Automake will do one of two things with it. If a suffix rule exists for turning files with the unrecognized extension into ` .o ' files, then automake will treat this file as it will any other source file (see section 9.12 Support for Other Languages ). Otherwise, the file will be ignored as though it were a header file.

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 de>subdir-objectsde> 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 de>subdir-objectsde> enabled, `sub/dir/file.c ' will be compiled to `sub/dir/file.o '. Some people prefer this mode of operation. You can specify de>subdir-objectsde> in de>AUTOMAKE_OPTIONSde> (see section 17. Changing Automake's Behavior ).

 

` EXTRA_maude_SOURCES '

Automake needs to know the list of files you intend to compile statically . For one thing, this is the only way Automake has of knowing what sort of language support a given ` Makefile.in ' requires. (5) This means that, for example, you can't put a configure substitution like ` @my_sources@ ' into a ` _SOURCES ' variable. If you intend to conditionally compile source files and use ` configure ' to substitute the appropriate object names into, e.g., ` _LDADD ' (see below), then you should list the corresponding source files in the ` EXTRA_ ' variable.

This variable also supports `dist_ ' and `nodist_ ' prefixes, e.g., `nodist_EXTRA_maude_SOURCES '.

 

` maude_AR '

A static library is created by default by invoking de>$(AR) crude> 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 variable set like so:

libmaude_a_AR = $(CXX) -ar -o

 

` maude_LIBADD '

Extra objects can be added to a library using the ` _LIBADD ' variable. This should be used for objects determined by de>configurede>.

 

` maude_LDADD '

Extra objects can be added to a shared library or a program by listing them in the ` _LDADD ' variable. This should be used for objects determined by de>configurede>.

`_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 de>AC_PATH_XTRAde>, you could link your program against the X libraries like so:

 

maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)

 

` maude_LDFLAGS '

This variable is used to pass extra flags to the link step of a program or a shared library.

 

` maude_LINK '

You can override the linker on a per-program basis. By default the linker is chosen according to the languages used by the program. For instance, a program that includes C++ source code would use the C++ compiler to link. The ` _LINK ' variable must hold the name of a command which can be passed all the ` .o ' file names as arguments. Note that the name of the underlying program is not passed to ` _LINK '; typically one uses ` $@ ':

 

maude_LINK = $(CCLD) -magic -o $@

 

` maude_CCASFLAGS '

` maude_CFLAGS '

` maude_CPPFLAGS '

` maude_CXXFLAGS '

` maude_FFLAGS '

` maude_GCJFLAGS '

` maude_LFLAGS '

` maude_OBJCFLAGS '

` maude_RFLAGS '

` maude_YFLAGS '

Automake allows you to set compilation flags on a per-program (or per-library) basis. A single source file can be included in several programs, and it will potentially be compiled with different flags for each program. This works for any language directly supported by Automake. The flags are ` _CCASFLAGS ', ` _CFLAGS ', ` _CPPFLAGS ', ` _CXXFLAGS ', ` _FFLAGS ', ` _GCJFLAGS ', ` _LFLAGS ', ` _OBJCFLAGS ', ` _RFLAGS ', and ` _YFLAGS '.

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)

 

` maude_DEPENDENCIES '

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 ` _DEPENDENCIES ' variable. Each program depends on the contents of such a variable, but no further interpretation is done.

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.

 

` maude_SHORTNAME '

On some platforms the allowable file names are very short. In order to support these systems and per-program compilation flags at the same time, Automake allows you to set a "short name" which will influence how intermediate object files are named. For instance, if you set ` maude_SHORTNAME ' to ` m ', then in the above per-program compilation flag example the object file would be named ` m-sample.o ' rather than ` maude-sample.o '. This facility is rarely needed in practice, and we recommend avoiding it until you find it is required.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.5 Special handling for LIBOBJS and ALLOCA

 

Automake explicitly recognizes the use of de>@LIBOBJS@de> and de>@ALLOCA@de>, and uses this information, plus the list of de>LIBOBJSde> files derived from `configure.in ' to automatically include the appropriate source files in the distribution (see section 15. What Goes in a Distribution ). These source files are also automatically handled in the dependency-tracking scheme; see See section 9.14 Automatic dependency tracking .

de>@LIBOBJS@de> and de>@ALLOCA@de> are specially recognized in any `_LDADD ' or `_LIBADD ' variable.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.6 Variables used when building a program

Occasionally it is useful to know which `Makefile ' variables Automake uses for compilations; for instance you might need to do your own compilation in some special cases.

Some variables are inherited from Autoconf; these are de>CCde>, de>CFLAGSde>, de>CPPFLAGSde>, de>DEFSde>, de>LDFLAGSde>, and de>LIBSde>.

There are some additional variables which Automake itself defines:

 

de>AM_CPPFLAGSde>

The contents of this variable are passed to every compilation which invokes the C preprocessor; it is a list of arguments to the preprocessor. For instance, ` -I ' and ` -D ' options should be listed here.

Automake already provides some `-I ' options automatically. In particular it generates `-I$(srcdir) ', `-I. ', and a `-I ' pointing to the directory holding `config.h ' (if you've used de>AC_CONFIG_HEADERSde> or de>AM_CONFIG_HEADERde>). You can disable the default `-I ' options using the `nostdinc ' option.

de>AM_CPPFLAGSde> is ignored in preference to a per-executable (or per-library) de>_CPPFLAGSde> variable if it is defined.

 

de>INCLUDESde>

This does the same job as ` AM_CPPFLAGS '. It is an older name for the same functionality. This variable is deprecated; we suggest using ` AM_CPPFLAGS ' instead.

 

de>AM_CFLAGSde>

This is the variable which the ` Makefile.am ' author can use to pass in additional C compiler flags. It is more fully documented elsewhere. In some situations, this is not used, in preference to the per-executable (or per-library) de>_CFLAGSde>.

 

de>COMPILEde>

This is the command used to actually compile a C source file. The filename is appended to form the complete command line.

 

de>AM_LDFLAGSde>

This is the variable which the ` Makefile.am ' author can use to pass in additional linker flags. In some situations, this is not used, in preference to the per-executable (or per-library) de>_LDFLAGSde>.

 

de>LINKde>

This is the command used to actually link a C program. It already includes ` -o $@ ' and the usual variable references (for instance, de>CFLAGSde>); it takes as "arguments" the names of the object files and libraries to link in.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.7 Yacc and Lex support

Automake has somewhat idiosyncratic support for Yacc and Lex.

Automake assumes that the `.c ' file generated by de>yaccde> (or de>lexde>) should be named using the basename of the input file. That is, for a yacc source file `foo.y ', Automake will cause the intermediate file to be named `foo.c ' (as opposed to `y.tab.c ', which is more traditional).

The extension of a yacc source file is used to determine the extension of the resulting `C ' or `C++ ' file. Files with the extension `.y ' will be turned into `.c ' files; likewise, `.yy ' will become `.cc '; `.y++ ', `c++ '; and `.yxx ', `.cxx '.

Likewise, lex source files can be used to generate `C ' or `C++ '; the extensions `.l ', `.ll ', `.l++ ', and `.lxx ' are recognized.

You should never explicitly mention the intermediate (`C ' or `C++ ') file in any `SOURCES ' variable; only list the source file.

The intermediate files generated by de>yaccde> (or de>lexde>) will be included in any distribution that is made. That way the user doesn't need to have de>yaccde> or de>lexde>.

If a de>yaccde> source file is seen, then your `configure.in ' must define the variable `YACC '. This is most easily done by invoking the macro `AC_PROG_YACC ' (see section `Particular Program Checks' in te>The Autoconf Manualte>).

When de>yaccde> is invoked, it is passed `YFLAGS ' and `AM_YFLAGS '. The former is a user variable and the latter is intended for the `Makefile.am ' author.

Similarly, if a de>lexde> source file is seen, then your `configure.in ' must define the variable `LEX '. You can use `AC_PROG_LEX ' to do this (see section `Particular Program Checks' in te>The Autoconf Manualte>), but using de>AM_PROG_LEXde> macro (see section 5.6 Autoconf macros supplied with Automake ) is recommended.

When de>lexde> is invoked, it is passed `LFLAGS ' and `AM_LFLAGS '. The former is a user variable and the latter is intended for the `Makefile.am ' author.

 

Automake makes it possible to include multiple de>yaccde> (or de>lexde>) source files in a single program. When there is more than one distinct de>yaccde> (or de>lexde>) source file in a directory, Automake uses a small program called de>ylwrapde> to run de>yaccde> (or de>lexde>) in a subdirectory. This is necessary because yacc's output filename is fixed, and a parallel make could conceivably invoke more than one instance of de>yaccde> simultaneously. The de>ylwrapde> program is distributed with Automake. It should appear in the directory specified by `AC_CONFIG_AUX_DIR ' (see section `Finding `configure' Input' in te>The Autoconf Manualte>), or the current directory if that macro is not used in `configure.in '.

For de>yaccde>, simply managing locking is insufficient. The output of de>yaccde> always uses the same symbol names internally, so it isn't possible to link two de>yaccde> parsers into the same executable.

We recommend using the following renaming hack used in de>gdbde>:

#define yymaxdepth c_maxdepth #define yyparse c_parse #define yylex c_lex #define yyerror c_error #define yylval c_lval #define yychar c_char #define yydebug c_debug #define yypact c_pact #define yyr1 c_r1 #define yyr2 c_r2 #define yydef c_def #define yychk c_chk #define yypgo c_pgo #define yyact c_act #define yyexca c_exca #define yyerrflag c_errflag #define yynerrs c_nerrs #define yyps c_ps #define yypv c_pv #define yys c_s #define yy_yys c_yys #define yystate c_state #define yytmp c_tmp #define yyv c_v #define yy_yyv c_yyv #define yyval c_val #define yylloc c_lloc #define yyreds c_reds #define yytoks c_toks #define yylhs c_yylhs #define yylen c_yylen #define yydefred c_yydefred #define yydgoto c_yydgoto #define yysindex c_yysindex #define yyrindex c_yyrindex #define yygindex c_yygindex #define yytable c_yytable #define yycheck c_yycheck #define yyname c_yyname #define yyrule c_yyrule

For each define, replace the `c_ ' prefix with whatever you like. These defines work for de>bisonde>, de>byaccde>, and traditional de>yaccde>s. If you find a parser generator that uses a symbol not covered here, please report the new name so it can be added to the list.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.8 C++ Support

 

Automake includes full support for C++.

Any package including C++ code must define the output variable `CXX ' in `configure.in '; the simplest way to do this is to use the de>AC_PROG_CXXde> macro (see section `Particular Program Checks' in te>The Autoconf Manualte>).

A few additional variables are defined when a C++ source file is seen:

 

de>CXXde>

The name of the C++ compiler.

 

de>CXXFLAGSde>

Any flags to pass to the C++ compiler.

 

de>AM_CXXFLAGSde>

The maintainer's variant of de>CXXFLAGSde>.

 

de>CXXCOMPILEde>

The command used to actually compile a C++ source file. The file name is appended to form the complete command line.

 

de>CXXLINKde>

The command used to actually link a C++ program.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.9 Assembly Support

Automake includes some support for assembly code.

The variable de>CCASde> holds the name of the compiler used to build assembly code. This compiler must work a bit like a C compiler; in particular it must accept `-c ' and `-o '. The value of de>CCASFLAGSde> is passed to the compilation.

You are required to set de>CCASde> and de>CCASFLAGSde> via `configure.in '. The autoconf macro de>AM_PROG_ASde> will do this for you. Unless they are already set, it simply sets de>CCASde> to the C compiler and de>CCASFLAGSde> to the C compiler flags.

Only the suffixes `.s ' and `.S ' are recognized by de>automakede> as being files containing assembly code.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.10 Fortran 77 Support

 

Automake includes full support for Fortran 77.

Any package including Fortran 77 code must define the output variable `F77 ' in `configure.in '; the simplest way to do this is to use the de>AC_PROG_F77de> macro (see section `Particular Program Checks' in te>The Autoconf Manualte>). See section 9.10.4 Fortran 77 and Autoconf .

A few additional variables are defined when a Fortran 77 source file is seen:

 

de>F77de>

The name of the Fortran 77 compiler.

 

de>FFLAGSde>

Any flags to pass to the Fortran 77 compiler.

 

de>AM_FFLAGSde>

The maintainer's variant of de>FFLAGSde>.

 

de>RFLAGSde>

Any flags to pass to the Ratfor compiler.

 

de>AM_RFLAGSde>

The maintainer's variant of de>RFLAGSde>.

 

de>F77COMPILEde>

The command used to actually compile a Fortran 77 source file. The file name is appended to form the complete command line.

 

de>FLINKde>

The command used to actually link a pure Fortran 77 program or shared library.

 

Automake can handle preprocessing Fortran 77 and Ratfor source files in addition to compiling them(6) . Automake also contains some support for creating programs and shared libraries that are a mixture of Fortran 77 and other languages (see section 9.10.3 Mixing Fortran 77 With C and C++ ).

These issues are covered in the following sections.

 

9.10.1 Preprocessing Fortran 77
9.10.2 Compiling Fortran 77 Files
9.10.3 Mixing Fortran 77 With C and C++
9.10.4 Fortran 77 and Autoconf

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.10.1 Preprocessing Fortran 77

 

`N.f ' is made automatically from `N.F ' or `N.r '. This rule runs just the preprocessor to convert a preprocessable Fortran 77 or Ratfor source file into a strict Fortran 77 source file. The precise command used is as follows:

 

` .F '

de>$(F77) -F $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)de>

 

` .r '

de>$(F77) -F $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)de>

 

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.10.2 Compiling Fortran 77 Files

`N.o ' is made automatically from `N.f ', `N.F ' or `N.r ' by running the Fortran 77 compiler. The precise command used is as follows:

 

` .f '

de>$(F77) -c $(AM_FFLAGS) $(FFLAGS)de>

 

` .F '

de>$(F77) -c $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)de>

 

` .r '

de>$(F77) -c $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)de>

 

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.10.3 Mixing Fortran 77 With C and C++

 

Automake currently provides limited support for creating programs and shared libraries that are a mixture of Fortran 77 and C and/or C++. However, there are many other issues related to mixing Fortran 77 with other languages that are not (currently) handled by Automake, but that are handled by other packages(7) .

Automake can help in two ways:

 

1. Automatic selection of the linker depending on which combinations of source code.

    

2. Automatic selection of the appropriate linker flags (e.g. `-L ' and `-l ') to pass to the automatically selected linker in order to link in the appropriate Fortran 77 intrinsic and run-time libraries.

   These extra Fortran 77 linker flags are supplied in the output variable de>FLIBSde> by the de>AC_F77_LIBRARY_LDFLAGSde> Autoconf macro supplied with newer versions of Autoconf (Autoconf version 2.13 and later). See section `Fortran 77 Compiler Characteristics' in te>The Autoconfte>.

If Automake detects that a program or shared library (as mentioned in some de>_PROGRAMSde> or de>_LTLIBRARIESde> primary) contains source code that is a mixture of Fortran 77 and C and/or C++, then it requires that the macro de>AC_F77_LIBRARY_LDFLAGSde> be called in `configure.in ', and that either de>$(FLIBS)de> or de>@FLIBS@de> appear in the appropriate de>_LDADDde> (for programs) or de>_LIBADDde> (for shared libraries) variables. It is the responsibility of the person writing the `Makefile.am ' to make sure that de>$(FLIBS)de> or de>@FLIBS@de> appears in the appropriate de>_LDADDde> or de>_LIBADDde> variable.

 

For example, consider the following `Makefile.am ':

 

bin_PROGRAMS = foo foo_SOURCES = main.cc foo.f foo_LDADD = libfoo.la @FLIBS@ pkglib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = bar.f baz.c zardoz.cc libfoo_la_LIBADD = $(FLIBS)

In this case, Automake will insist that de>AC_F77_LIBRARY_LDFLAGSde> is mentioned in `configure.in '. Also, if de>@FLIBS@de> hadn't been mentioned in de>foo_LDADDde> and de>libfoo_la_LIBADDde>, then Automake would have issued a warning.

 

9.10.3.1 How the Linker is Chosen

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.10.3.1 How the Linker is Chosen

 

The following diagram demonstrates under what conditions a particular linker is chosen by Automake.

For example, if Fortran 77, C and C++ source code were to be compiled into a program, then the C++ linker will be used. In this case, if the C or Fortran 77 linkers required any special libraries that weren't included by the C++ linker, then they must be manually added to an de>_LDADDde> or de>_LIBADDde> variable by the user writing the `Makefile.am '.

 

/ Linker source / code / C C++ Fortran ----------------- +---------+---------+---------+ | | | | C | x | | | | | | | +---------+---------+---------+ | | | | C++ | | x | | | | | | +---------+---------+---------+ | | | | Fortran | | | x | | | | | +---------+---------+---------+ | | | | C + C++ | | x | | | | | | +---------+---------+---------+ | | | | C + Fortran | | | x | | | | | +---------+---------+---------+ | | | | C++ + Fortran | | x | | | | | | +---------+---------+---------+ | | | | C + C++ + Fortran | | x | | | | | | +---------+---------+---------+

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.10.4 Fortran 77 and Autoconf

The current Automake support for Fortran 77 requires a recent enough version of Autoconf that also includes support for Fortran 77. Full Fortran 77 support was added to Autoconf 2.13, so you will want to use that version of Autoconf or later.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.11 Java Support

 

Automake includes support for compiled Java, using de>gcjde>, the Java front end to the GNU Compiler Collection.

Any package including Java code to be compiled must define the output variable `GCJ ' in `configure.in '; the variable `GCJFLAGS ' must also be defined somehow (either in `configure.in ' or `Makefile.am '). The simplest way to do this is to use the de>AM_PROG_GCJde> macro.

 

By default, programs including Java source files are linked with de>gcjde>.

As always, the contents of `AM_GCJFLAGS ' are passed to every compilation invoking de>gcjde> (in its role as an ahead-of-time compiler -- when invoking it to create `.class ' files, `AM_JAVACFLAGS ' is used instead). If it is necessary to pass options to de>gcjde> from `Makefile.am ', this variable, and not the user variable `GCJFLAGS ', should be used.

 

de>gcjde> can be used to compile `.java ', `.class ', `.zip ', or `.jar ' files.

When linking, de>gcjde> requires that the main class be specified using the `--main= ' option. The easiest way to do this is to use the de>_LDFLAGSde> variable for the program.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.12 Support for Other Languages

Automake currently only includes full support for C, C++ (see section 9.8 C++ Support ), Fortran 77 (see section 9.10 Fortran 77 Support ), and Java (see section 9.11 Java Support ). There is only rudimentary support for other languages, support for which will be improved based on user demand.

Some limited support for adding your own languages is available via the suffix rule handling; see 18.2 Handling new file extensions .

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.13 Automatic de-ANSI-fication

 

Although the GNU standards allow the use of ANSI C, this can have the effect of limiting portability of a package to some older compilers (notably the SunOS C compiler).

Automake allows you to work around this problem on such machines by de-ANSI-fying each source file before the actual compilation takes place.

 

If the `Makefile.am ' variable de>AUTOMAKE_OPTIONSde> (see section 17. Changing Automake's Behavior ) contains the option de>ansi2knrde> then code to handle de-ANSI-fication is inserted into the generated `Makefile.in '.

This causes each C source file in the directory to be treated as ANSI C. If an ANSI C compiler is available, it is used. If no ANSI C compiler is available, the de>ansi2knrde> program is used to convert the source files into K&R C, which is then compiled.

The de>ansi2knrde> program is simple-minded. It assumes the source code will be formatted in a particular way; see the de>ansi2knrde> man page for details.

Support for de-ANSI-fication requires the source files `ansi2knr.c ' and `ansi2knr.1 ' to be in the same package as the ANSI C source; these files are distributed with Automake. Also, the package `configure.in ' must call the macro de>AM_C_PROTOTYPESde> (see section 5.6 Autoconf macros supplied with Automake ).

Automake also handles finding the de>ansi2knrde> support files in some other directory in the current package. This is done by prepending the relative path to the appropriate directory to the de>ansi2knrde> option. For instance, suppose the package has ANSI C code in the `src ' and `lib ' subdirs. The files `ansi2knr.c ' and `ansi2knr.1 ' appear in `lib '. Then this could appear in `src/Makefile.am ':

 

AUTOMAKE_OPTIONS = ../lib/ansi2knr

If no directory prefix is given, the files are assumed to be in the current directory.

Files mentioned in de>LIBOBJSde> which need de-ANSI-fication will not be automatically handled. That's because de>configurede> will generate an object name like `regex.o ', while de>makede> will be looking for `regex_.o ' (when de-ANSI-fying). Eventually this problem will be fixed via de>autoconfde> magic, but for now you must put this code into your `configure.in ', just before the de>AC_OUTPUTde> call:

 

# This is necessary so that .o files in LIBOBJS are also built via # the ANSI2KNR-filtering rules. LIBOBJS=`echo $LIBOBJS|sed 's//.o //$U.o /g;s//.o$//$U.o/'`

Note that automatic de-ANSI-fication will not work when the package is being built for a different host architecture. That is because automake currently has no way to build de>ansi2knrde> for the build machine.

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.14 Automatic dependency tracking

As a developer it is often painful to continually update the `Makefile.in ' whenever the include-file dependencies change in a project. Automake supplies a way to automatically track dependency changes.

 

Automake always uses complete dependencies for a compilation, including system headers. Automake's model is that dependency computation should be a side effect of the build. To this end, dependencies are computed by running all compilations through a special wrapper program called de>depcompde>. de>depcompde> understands how to coax many different C and C++ compilers into generating dependency information in the format it requires. de>automake -ade> will install de>depcompde> into your source tree for you. If de>depcompde> can't figure out how to properly invoke your compiler, dependency tracking will simply be disabled for your build.

 

Experience with earlier versions of Automake (8) taught us that it is not reliable to generate dependencies only on the maintainer's system, as configurations vary too much. So instead Automake implements dependency tracking at build time.

Automatic dependency tracking can be suppressed by putting de>no-dependenciesde> in the variable de>AUTOMAKE_OPTIONSde>, or passing de>no-dependenciesde> as an argument to de>AM_INIT_AUTOMAKEde> (this should be the prefered way). Or, you can invoke de>automakede> with the de>-ide> option. Dependency tracking is enabled by default.

 

The person building your package also can choose to disable dependency tracking by configuring with de>--disable-dependency-trackingde>.

 

 

---

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

9.15 Support for executable extensions

 

On some platforms, such as Windows, executables are expected to have an extension such as `.exe '. On these platforms, some compilers (GCC among them) will automatically generate `foo.exe ' when asked to generate `foo '.

Automake provides mostly-transparent support for this. Unfortunately mostly doesn't yet mean fully . Until the English dictionary is revised, you will have to assist Automake if your package must support those platforms.

One thing you must be aware of is that, internally, Automake rewrites something like this:

 

bin_PROGRAMS = liver

to this:

 

bin_PROGRAMS = liver$(EXEEXT)

The targets Automake generates are likewise given the `$(EXEEXT) ' extension. de>EXEEXTde>

However, Automake cannot apply this rewriting to de>configurede> substitutions. This means that if you are conditionally building a program using such a substitution, then your `configure.in ' must take care to add `$(EXEEXT) ' when constructing the output variable.

With Autoconf 2.13 and earlier, you must explicitly use de>AC_EXEEXTde> to get this support. With Autoconf 2.50, de>AC_EXEEXTde> is run automatically if you configure a compiler (say, through de>AC_PROG_CCde>).

Sometimes maintainers like to write an explicit link rule for their program. Without executable extension support, this is easy--you simply write a target with the same name as the program. However, when executable extension support is enabled, you must instead add the `$(EXEEXT) ' suffix.

Unfortunately, due to the change in Autoconf 2.50, this means you must always add this extension. However, this is a problem for maintainers who know their package will never run on a platform that has executable extensions. For those maintainers, the de>no-exeextde> option (see section 17. Changing Automake's Behavior ) will disable this feature. This works in a fairly ugly way; if de>no-exeextde> is seen, then the presence of a target named de>foode> in `Makefile.am ' will override an automake-generated target of the form de>foo$(EXEEXT)de>. Without the de>no-exeextde> option, this use will give an error.

 

 

[ << ]

[ >> ]

[Top ]

[Contents ]

[Index ]

[ ? ]

This document was generated by Jeff Bailey on December, 24 2002 using texi2html