最近花了些时间整理autotool的资料，发现网上的非常零散，之前有个帖子是从网上摘录的。
后来才发现，很多内容在gnu 的官网上的pdf都有描述，现在摘录关键部分如下：
automake中的：
8.4 Program and Library Variables
Associated with each program is a collection of variables that 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 that 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 8.17 [Support for Other Languages], page 78). 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 ‘subdir-objects’ is in
effect in the current directory then the ‘.o’ file will be put into the subdirec- tory named after the source file. For instance, with ‘subdir-objects’ enabled,
‘sub/dir/file.c’ will be compiled to ‘sub/dir/file.o’. Some people pre- fer this mode of operation. You can specify ‘subdir-objects’ in AUTOMAKE_ OPTIONS (see Chapter 17 [Options], page 104).
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.4 This means that, for example, you can’t put a configure substitution like ‘@my_sources@’ into a ‘_SOURCES’ vari- able. 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. For instance, nodist_ EXTRA_maude_SOURCES would list extra sources that may need to be built, but should not be distributed.
maude_AR A static library is created by default by invoking ‘$(AR) $(ARFLAGS)’ 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 that 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. For in- stance, this should be used for objects determined by configure (see Section 8.2 [A Library], page 56).
In the case of libtool libraries, maude_LIBADD can also refer to other libtool libraries.
maude_LDADD
Extra objects (‘*.$(OBJEXT)’) and libraries (‘*.a’, ‘*.la’) can be added to a program by listing them in the _LDADD variable. For instance, this should be used for objects determined by configure (see Section 8.1.2 [Linking], page 53).
_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.ac’ uses AC_PATH_XTRA, you could link your program against the X libraries like so:
maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)
We recommend that you use ‘-l’ and ‘-L’ only when referring to third-party libraries, and give the explicit file names of any library built by your package.
4 There are other, more obscure reasons for this limitation as well.
Doing so will ensure that maude_DEPENDENCIES (see below) is correctly defined by default.
maude_LDFLAGS
This variable is used to pass extra flags to the link step of a program or a shared library. It overrides the AM_LDFLAGS variable.
maude_LIBTOOLFLAGS
This variable is used to pass extra options to libtool. It overrides the
AM_LIBTOOLFLAGS variable. These options are output before libtool’s
‘--mode=MODE ’ option, so they should not be mode-specific options (those belong to the compiler or linker flags). See Section 8.3.7 [Libtool Flags], page 61.
maude_DEPENDENCIES
It is also occasionally useful to have a target (program or library) depend on some other file that is not actually part of that target. This can be done using the _DEPENDENCIES variable. Each target depends on the contents of such a variable, but no further interpretation is done.
Since these dependencies are associated to the link rule used to create the programs they should normally list files used by the link command. That is
‘*.$(OBJEXT)’, ‘*.a’, or ‘*.la’ files for programs; ‘*.lo’ and ‘*.la’ files for Libtool libraries; and ‘*.$(OBJEXT)’ files for static libraries. In rare cases you may need to add other kinds of files such as linker scripts, but listing a source file in _DEPENDENCIES is wrong. If some source file needs to be built before all the components of a program are built, consider using the BUILT_SOURCES variable (see Section 9.4 [Sources], page 82).
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.
_DEPENDENCIES is more likely used to perform conditional compilation using an AC_SUBST variable that contains a list of objects. See Section 8.1.3 [Conditional Sources], page 54, and Section 8.3.4 [Conditional Libtool Sources], page 59.
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 that can be passed all the ‘.o’ file names and libraries to link against as arguments. Note that the name of the underlying program is not passed to _LINK; typically one uses ‘$@’:
maude_LINK = $(CCLD) -magic -o $@
If a _LINK variable is not supplied, it may still be generated and used by Au- tomake due to the use of per-target link flags such as _CFLAGS, _LDFLAGS or
_LIBTOOLFLAGS, in cases where they apply.
maude_CCASFLAGS maude_CFLAGS maude_CPPFLAGS maude_CXXFLAGS maude_FFLAGS maude_GCJFLAGS maude_LFLAGS maude_OBJCFLAGS maude_RFLAGS maude_UPCFLAGS 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 poten- tially be compiled with different flags for each program. This works for any lan- guage directly supported by Automake. These per-target compilation flags are
‘_CCASFLAGS’, ‘_CFLAGS’, ‘_CPPFLAGS’, ‘_CXXFLAGS’, ‘_FFLAGS’, ‘_GCJFLAGS’,
‘_LFLAGS’, ‘_OBJCFLAGS’, ‘_RFLAGS’, ‘_UPCFLAGS’, and ‘_YFLAGS’.
When using a per-target 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’. (See also Section 27.7 [Renamed Objects], page 130.) The use of per-target compilation flags with C sources requires that the macro AM_PROG_CC_C_O be called from
‘configure.ac’.
In compilations with per-target flags, the ordinary ‘AM_’ form of the flags vari- able 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)
See Section 27.6 [Flag Variables Ordering], page 127, for more discussion about the interaction between user variables, ‘AM_’ shadow variables, and per-target variables.
maude_SHORTNAME
On some platforms the allowable file names are very short. In order to support these systems and per-target compilation flags at the same time, Automake allows you to set a “short name” that will influence how intermediate object files are named. For instance, in the following example,
bin_PROGRAMS = maude maude_CPPFLAGS = -DSOMEFLAG maude_SHORTNAME = m maude_SOURCES = sample.c ...
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.
autoconf中的：
4.8 Substitutions in Makefiles
Each subdirectory in a distribution that contains something to be compiled or installed
should come with a file ‘Makefile.in’, from which configure creates a file ‘Makefile’ in
that directory. To create ‘Makefile’, configure performs a simple variable substitution,
replacing occurrences of ‘@variable @’ in ‘Makefile.in’ with the value that configure has
determined for that variable. Variables that are substituted into output files in this way
are called output variables. They are ordinary shell variables that are set in configure. To
make configure substitute a particular variable into the output files, the macro AC_SUBST
must be called with that variable name as an argument. Any occurrences of ‘@variable @’
for other variables are left unchanged. See Section 7.2 [Setting Output Variables], page 110,
for more information on creating output variables with AC_SUBST.
A software package that uses a configure script should be distributed with a file
‘Makefile.in’, but no makefile; that way, the user has to properly configure the pack-
age for the local system before compiling it.
See Section “Makefile Conventions” in The GNU Coding Standards, for more information
on what to put in makefiles.
4.8.1 Preset Output Variables
Some output variables are preset by the Autoconf macros. Some of the Autoconf macros
set additional output variables, which are mentioned in the descriptions for those macros.
See Section B.2 [Output Variable Index], page 354, for a complete list of output variables.
See Section 4.8.2 [Installation Directory Variables], page 27, for the list of the preset ones
related to installation directories. Below are listed the other preset ones, many of which are
precious variables (see Section 7.2 [Setting Output Variables], page 110, AC_ARG_VAR).
figuration Actions], page 21) may also be used during configure tests. For example, it is
permissible to reference ‘$srcdir’ when constructing a list of directories to pass via option
‘-I’ during a compiler feature check. When used in this manner, coupled with the fact that
configure is always run from the top build directory, it is sufficient to use just ‘$srcdir’
instead of ‘$top_srcdir’.
CFLAGS
[Variable]
Debugging and optimization options for the C compiler. If it is not set in the envi-
ronment when configure runs, the default value is set when you call AC_PROG_CC (or
empty if you don’t). configure uses this variable when compiling or linking programs
to test for C features.
If a compiler option affects only the behavior of the preprocessor (e.g., ‘-Dname ’), it
should be put into CPPFLAGS instead. If it affects only the linker (e.g., ‘-Ldirectory ’),
it should be put into LDFLAGS instead. If it affects only the compiler proper, CFLAGS is
the natural home for it. If an option affects multiple phases of the compiler, though,
matters get tricky. One approach to put such options directly into CC, e.g., CC=’gcc
-m64’. Another is to put them into both CPPFLAGS and LDFLAGS, but not into CFLAGS.
However, remember that some ‘Makefile’ variables are reserved by the GNU Coding
Standards for the use of the “user”—the person building the package. For instance,
CFLAGS is one such variable.
Sometimes package developers are tempted to set user variables such as CFLAGS be-
cause it appears to make their job easier. However, the package itself should never set
a user variable, particularly not to include switches that are required for proper com-
pilation of the package. Since these variables are documented as being for the package
builder, that person rightfully expects to be able to override any of these variables at
build time. If the package developer needs to add switches without interfering with
the user, the proper way to do that is to introduce an additional variable. Automake
makes this easy by introducing AM_CFLAGS (see Section “Flag Variables Ordering” in
GNU Automake), but the concept is the same even if Automake is not used.
configure_input
[Variable]
A comment saying that the file was generated automatically by configure and giving
the name of the input file. AC_OUTPUT adds a comment line containing this variable to
the top of every makefile it creates. For other files, you should reference this variable
in a comment at the top of each input file. For example, an input shell script should
begin like this:
#!/bin/sh
# @configure_input@
The presence of that line also reminds people editing the file that it needs to be
processed by configure in order to be used.
CPPFLAGS
[Variable]
Preprocessor options for the C, C++, Objective C, and Objective C++ preprocessors
and compilers. If it is not set in the environment when configure runs, the de-
fault value is empty. configure uses this variable when preprocessing or compiling
programs to test for C, C++, Objective C, and Objective C++ features.
Chapter 4: Initialization and Output Files
25
This variable’s contents should contain options like ‘-I’, ‘-D’, and ‘-U’ that affect only
the behavior of the preprocessor. Please see the explanation of CFLAGS for what you
can do if an option affects other phases of the compiler as well.
Currently, configure always links as part of a single invocation of the compiler that
also preprocesses and compiles, so it uses this variable also when linking programs.
However, it is unwise to depend on this behavior because the GNU Coding Standards
do not require it and many packages do not use CPPFLAGS when linking programs.
See Section 7.3 [Special Chars in Variables], page 112, for limitations that CPPFLAGS
might run into.
CXXFLAGS
[Variable]
DEFS
Debugging and optimization options for the C++ compiler. It acts like CFLAGS, but
for C++ instead of C.
[Variable]
‘-D’ options to pass to the C compiler. If AC_CONFIG_HEADERS is called, configure
replaces ‘@DEFS@’ with ‘-DHAVE_CONFIG_H’ instead (see Section 4.9 [Configuration
Headers], page 33). This variable is not defined while configure is performing its
tests, only when creating the output files. See Section 7.2 [Setting Output Variables],
ECHO_C
ECHO_N
ECHO_T
[Variable]
[Variable]
[Variable]
How does one suppress the trailing newline from echo for question-answer message
pairs? These variables provide a way:
echo $ECHO_N "And the winner is... $ECHO_C"
sleep 100000000000
echo "${ECHO_T}dead."
Some old and uncommon echo implementations offer no means to achieve this, in
which case ECHO_T is set to tab. You might not want to use it.
ERLCFLAGS
[Variable]
Debugging and optimization options for the Erlang compiler. If it is not set in the
environment when configure runs, the default value is empty. configure uses this
variable when compiling programs to test for Erlang features.
FCFLAGS
[Variable]
Debugging and optimization options for the Fortran compiler. If it is not set in the
environment when configure runs, the default value is set when you call AC_PROG_
FC (or empty if you don’t). configure uses this variable when compiling or linking
programs to test for Fortran features.
FFLAGS
[Variable]
Debugging and optimization options for the Fortran 77 compiler. If it is not set in the
environment when configure runs, the default value is set when you call AC_PROG_
F77 (or empty if you don’t). configure uses this variable when compiling or linking
programs to test for Fortran 77 features.
26
LDFLAGS
Autoconf
[Variable]
LIBS
Options for the linker. If it is not set in the environment when configure runs, the
default value is empty. configure uses this variable when linking programs to test
for C, C++, Objective C, Objective C++, and Fortran features.
This variable’s contents should contain options like ‘-s’ and ‘-L’ that affect only the
behavior of the linker. Please see the explanation of CFLAGS for what you can do if
an option also affects other phases of the compiler.
Don’t use this variable to pass library names (‘-l’) to the linker; use LIBS instead.
[Variable]
‘-l’ options to pass to the linker. The default value is empty, but some Autoconf
macros may prepend extra libraries to this variable if those libraries are found and
provide necessary functions, see Section 5.4 [Libraries], page 49. configure uses this
variable when linking programs to test for C, C++, Objective C, Objective C++, and
Fortran features.
OBJCFLAGS
[Variable]
Debugging and optimization options for the Objective C compiler. It acts like CFLAGS,
but for Objective C instead of C.
OBJCXXFLAGS
[Variable]
Debugging and optimization options for the Objective C++ compiler. It acts like
CXXFLAGS, but for Objective C++ instead of C++.
builddir
Rigorously equal to ‘.’. Added for symmetry only.
abs_builddir
Absolute name of builddir.
top_builddir
[Variable]
[Variable]
[Variable]
The relative name of the top level of the current build tree. In the top-level directory,
this is the same as builddir.
top_build_prefix
[Variable]
The relative name of the top level of the current build tree with final slash if nonemtpy.
This is the same as top_builddir, except that it contains zero or more runs of ../,
so it should not be appended with a slash for concatenation. This helps for make
implementations that otherwise do not treat ‘./file’ and ‘file’ as equal in the
toplevel build directory.
abs_top_builddir
Absolute name of top_builddir.
srcdir
The name of the directory that contains the source code for that makefile.
abs_srcdir
Absolute name of srcdir.
[Variable]
[Variable]
[Variable]
Chapter 4: Initialization and Output Files
top_srcdir
27
[Variable]
The name of the top-level source code directory for the package. In the top-level
directory, this is the same as srcdir.
abs_top_srcdir
Absolute name of top_srcdir.
4.8.2 Installation Directory Variables
[Variable]
The following variables specify the directories for package installation, see Section “Variables
for Installation Directories” in The GNU Coding Standards, for more information. Each
variable corresponds to an argument of configure; trailing slashes are stripped so that
expressions such as ‘${prefix}/lib’ expand with only one slash between directory names.
See the end of this section for details on when and how to use these variables.
bindir
The directory for installing executables that users run.
datadir
[Variable]
[Variable]
The directory for installing idiosyncratic read-only architecture-independent data.
datarootdir
[Variable]
The root of the directory tree for read-only architecture-independent data files.
docdir
[Variable]
The directory for installing documentation files (other than Info and man).
dvidir
The directory for installing documentation files in DVI format.
exec_prefix
[Variable]
[Variable]
The installation prefix for architecture-dependent files. By default it’s the same as
prefix. You should avoid installing anything directly to exec_prefix. However, the
default value for directories containing architecture-dependent files should be relative
to exec_prefix.
htmldir
The directory for installing HTML documentation.
includedir
The directory for installing C header files.
infodir
The directory for installing documentation in Info format.
libdir
The directory for installing object code libraries.
libexecdir
The directory for installing executables that other programs run.
[Variable]
[Variable]
[Variable]
[Variable]
[Variable]
28
localedir
Autoconf
[Variable]
The directory for installing locale-dependent but architecture-independent data, such
as message catalogs. This directory usually has a subdirectory per locale.
localstatedir
The directory for installing modifiable single-machine data.
mandir
The top-level directory for installing documentation in man format.
oldincludedir
The directory for installing C header files for non-GCC compilers.
pdfdir
The directory for installing PDF documentation.
prefix
[Variable]
[Variable]
[Variable]
[Variable]
[Variable]
The common installation prefix for all files. If exec_prefix is defined to a different
value, prefix is used only for architecture-independent files.
psdir
The directory for installing PostScript documentation.
sbindir
The directory for installing executables that system administrators run.
sharedstatedir
The directory for installing modifiable architecture-independent data.
sysconfdir
The directory for installing read-only single-machine data.
[Variable]
[Variable]
[Variable]
[Variable]
Most of these variables have values that rely on prefix or exec_prefix. It is deliberate
that the directory output variables keep them unexpanded: typically ‘@datarootdir@’ is
replaced by ‘${prefix}/share’, not ‘/usr/local/share’, and ‘@datadir@’ is replaced by
‘${datarootdir}’.
This behavior is mandated by the GNU Coding Standards, so that when the user runs:
‘make’
she can still specify a different prefix from the one specified to configure, in
which case, if needed, the package should hard code dependencies corresponding
to the make-specified prefix.
‘make install’
she can specify a different installation location, in which case the package must
still depend on the location which was compiled in (i.e., never recompile when
‘make install’ is run). This is an extremely important feature, as many people
may decide to install all the files of a package grouped together, and then install
links from the final locations to there.
In order to support these features, it is essential that datarootdir remains defined as
‘${prefix}/share’, so that its value can be expanded based on the current value of prefix.
Chapter 4: Initialization and Output Files
29
A corollary is that you should not use these variables except in makefiles. For instance, in-
stead of trying to evaluate datadir in ‘configure’ and hard-coding it in makefiles using e.g.,
‘AC_DEFINE_UNQUOTED([DATADIR], ["$datadir"], [Data directory.])’, you should add
‘-DDATADIR=’$(datadir)’’ to your makefile’s definition of CPPFLAGS (AM_CPPFLAGS if you
are also using Automake).
Similarly, you should not rely on AC_CONFIG_FILES to replace bindir and friends in
your shell scripts and other files; instead, let make manage their replacement. For instance
Autoconf ships templates of its shell scripts ending with ‘.in’, and uses a makefile snippet
similar to the following to build scripts like autoheader and autom4te:
edit = sed \
-e ’s|@bindir[@]|$(bindir)|g’ \
-e ’s|@pkgdatadir[@]|$(pkgdatadir)|g’ \
-e ’s|@prefix[@]|$(prefix)|g’
autoheader autom4te: Makefile
rm -f $@ $@.tmp
srcdir=’’; \
test -f ./$@.in || srcdir=$(srcdir)/; \
$(edit) $${srcdir}$@.in >$@.tmp
chmod +x $@.tmp
chmod a-w $@.tmp
mv $@.tmp $@
autoheader: $(srcdir)/autoheader.in
autom4te: $(srcdir)/autom4te.in
Some details are noteworthy:
‘@bindir[@]’
The brackets prevent configure from replacing ‘@bindir@’ in the Sed expres-
sion itself. Brackets are preferable to a backslash here, since Posix says ‘\@’ is
not portable.
‘$(bindir)’
Don’t use ‘@bindir@’! Use the matching makefile variable instead.
‘$(pkgdatadir)’
The example takes advantage of the variable ‘$(pkgdatadir)’ provided by Au-
tomake; it is equivalent to ‘$(datadir)/$(PACKAGE)’.
‘/’
Don’t use ‘/’ in the Sed expressions that replace file names since most likely the
variables you use, such as ‘$(bindir)’, contain ‘/’. Use a shell metacharacter
instead, such as ‘|’.
special characters
File names, file name components, and the value of VPATH should not contain
shell metacharacters or white space. See Section 7.3 [Special Chars in Variables],
30
dependency on ‘Makefile’
Autoconf
‘$@’
Since edit uses values that depend on the configuration specific values (prefix,
etc.) and not only on VERSION and so forth, the output depends on ‘Makefile’,
not ‘configure.ac’.
The main rule is generic, and uses ‘$@’ extensively to avoid the need for multiple
copies of the rule.
Separated dependencies and single suffix rules
You can’t use them! The above snippet cannot be (portably) rewritten as:
autoconf autoheader: Makefile
.in:
rm -f $@ $@.tmp
$(edit) $< >$@.tmp
chmod +x $@.tmp
mv $@.tmp $@
See Section 12.16 [Single Suffix Rules], page 256, for details.
‘$(srcdir)’
Be sure to specify the name of the source directory, otherwise the package won’t
support separated builds.
For the more specific installation of Erlang libraries, the following variables are defined:
ERLANG_INSTALL_LIB_DIR
[Variable]
The common parent directory of Erlang library installation directories. This variable
is set by calling the AC_ERLANG_SUBST_INSTALL_LIB_DIR macro in ‘configure.ac’.
ERLANG_INSTALL_LIB_DIR_library
[Variable]
The installation directory for Erlang library library. This variable is set by using the
‘AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR’ macro in ‘configure.ac’.
