Automake Multiple Programs
Most of the general complaints I've ever seen aimed at the Autotools are ultimately associated with Automake, in the final analysis. The reason for this is simple. 27.9 Handling Tools that Produce Many Outputs. This section describes a make idiom that can be used when a tool produces multiple output files. It is not specific to.
Automake - Building Programs and Libraries Go to the, section,. A large part of Automake's functionality is dedicated to making it easy to build programs and libraries. 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 ( `noinst'). For instance: binPROGRAMS = hello In this simple case, the resulting `Makefile.in' will contain code to generate a program named hello. The variable helloSOURCES is used to specify which source files get built into an executable: helloSOURCES = 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 ` progSOURCES' is needed, but not specified, then it defaults to the single file `prog.c'.
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 an `SOURCES' variable; this file should not be distributed. Lex ( `.l') and Yacc ( `.y') files can also be listed; see section.
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' were conditionally included in hello, the `Makefile.am' would contain: EXTRAhelloSOURCES = hello-linux.c Similarly, sometimes it is useful to determine the programs that are to be built at configure time. For instance, GNU cpio only builds 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 EXTRAPROGRAMS. 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 ` progLDADD' 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): binPROGRAMS = cpio pax @MT@ libexecPROGRAMS = @RMT@ EXTRAPROGRAMS = mt rmt LDADD =./lib/libcpio.a @INTLLIBS@ rmtLDADD = cpioSOURCES =.
PaxSOURCES =. MtSOURCES =. RmtSOURCES =. ` progLDADD' is inappropriate for passing program-specific linker flags (except for `-l' and `-L').
So, use the ` progLDFLAGS' 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 ` progDEPENDENCIES' variable. Each program depends on the contents of such a variable, but no further interpretation is done. If ` progDEPENDENCIES' is not supplied, it is computed by Automake. The automatically-assigned value is the contents of ` progLDADD', with most configure substitutions, `-l', and `-L' 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 ` progDEPENDENCIES' to be generated. Building a library is much like building a program. In this case, the name of the primary is `LIBRARIES'. Libraries can be installed in libdir or pkglibdir. See section, 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: noinstLIBRARIES = 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 ), so the `SOURCES' variable corresponding to `liblob.a' is `liblobaSOURCES', not `liblob.aSOURCES'. Extra objects can be added to a library using the ` libraryLIBADD' variable. This should be used for objects determined by configure. Again from cpio: libcpioaLIBADD = @LIBOBJS@ @ALLOCA@ Automake explicitly recognizes the use of @LIBOBJS@ and @ALLOCA@, and uses this information, plus the list of LIBOBJS files derived from `configure.in' to automatically include the appropriate source files in the distribution (see section ). These source files are also automatically handled in the dependency-tracking scheme; see See section.
@LIBOBJS@ and @ALLOCA@ are specially recognized in any `LDADD' or `LIBADD' variable. Building shared libraries is a relatively complex matter.
For this reason, GNU Libtool (see section `Introduction' in The Libtool Manual) 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: libLTLIBRARIES = libgettext.la Note that shared libraries must be installed, so checkLTLIBRARIES is not allowed. However, noinstLTLIBRARIES is allowed. This feature should be used for libtool 'convenience libraries'.
For each library, the ` libraryLIBADD' variable contains the names of extra libtool objects ( `.lo' files) to add to the shared library. The ` libraryLDFLAGS' variable contains any additional libtool flags, such as `-version-info' or `-static'. Where an ordinary library might include @LIBOBJS@, a libtool library must use @LTLIBOBJS@. 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 EXTRALTLIBRARIES), Automake does not know the eventual installation directory; for such libraries you must add the `-rpath' option to the appropriate `LDFLAGS' variable by hand.
See section `The Libtool Manual' in The Libtool Manual, for more information. 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 CC, CFLAGS, CPPFLAGS, DEFS, LDFLAGS, and LIBS. There are some additional variables which Automake itself defines: INCLUDES A list of `-I' options.
This can be set in your `Makefile.am' if you have special directories you want to look in. Automake already provides some `-I' options automatically. In particular it generates `-I$(srcdir)' and a `-I' pointing to the directory holding `config.h' (if you've used ACCONFIGHEADER or AMCONFIGHEADER). INCLUDES can actually be used for other cpp options besides `-I'. For instance, it is sometimes used to pass arbitrary `-D' options to the compiler. COMPILE This is the command used to actually compile a C source file.
The filename is appended to form the complete command line. LINK This is the command used to actually link a C program.
Automake Tutorial
Automake has somewhat idiosyncratic support for Yacc and Lex. Automake assumes that the `.c' file generated by yacc (or lex) 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.
Automake 1.14
The intermediate files generated by yacc (or lex) will be included in any distribution that is made. That way the user doesn't need to have yacc or lex. If a yacc source file is seen, then your `configure.in' must define the variable `YACC'. This is most easily done by invoking the macro `ACPROGYACC' (see section `Particular Program Checks' in The Autoconf Manual). Similarly, if a lex source file is seen, then your `configure.in' must define the variable `LEX'. You can use `ACPROGLEX' to do this (see section `Particular Program Checks' in The Autoconf Manual).
Automake's lex support also requires that you use the `ACDECLYYTEXT' macro-automake needs to know the value of `LEXOUTPUTROOT'. This is all handled for you if you use the AMPROGLEX macro (see section ). Automake makes it possible to include multiple yacc (or lex) source files in a single program. Automake uses a small program called ylwrap to run yacc (or lex) 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 yacc simultaneously. The ylwrap program is distributed with Automake. It should appear in the directory specified by `ACCONFIGAUXDIR' (see section `Finding `configure' Input' in The Autoconf Manual), or the current directory if that macro is not used in `configure.in'.
For yacc, simply managing locking is insufficient. The output of yacc always uses the same symbol names internally, so it isn't possible to link two yacc parsers into the same executable.