2.4.2 amhello-1.0 Explained
Let us begin with the contents of configure.ac.
AC_INIT([amhello], [1.0], [bug-automake@gnu.org]) AM_INIT_AUTOMAKE([-Wall -Werror foreign]) AC_PROG_CC AC_CONFIG_HEADERS([config.h]) AC_CONFIG_FILES([ Makefile src/Makefile ]) AC_OUTPUT
This file is read by both autoconf (to create configure) and automake (to create the various Makefile.ins). It contains a series of M4 macros that will be expanded as shell code to finally form the configure script. We will not elaborate on the syntax of this file, because the Autoconf manual has a whole section about it (see Writing configure.ac).
The macros prefixed with AC_
are Autoconf macros, documented in the Autoconf manual (see Autoconf Macro Index). The macros that start with AM_
are Automake macros, documented later in this manual (see Macro Index).
The first two lines of configure.ac initialize Autoconf and Automake. AC_INIT
takes in as parameters the name of the package, its version number, and a contact address for bug-reports about the package (this address is output at the end of ./configure --help
, for instance). When adapting this setup to your own package, by all means please do not blindly copy Automake's address: use the mailing list of your package, or your own mail address.
The argument to AM_INIT_AUTOMAKE
is a list of options for automake (see Options). -Wall and -Werror ask automake to turn on all warnings and report them as errors. We are speaking of Automake warnings here, such as dubious instructions in Makefile.am. This has absolutely nothing to do with how the compiler will be called, even though it may support options with similar names. Using -Wall -Werror is a safe setting when starting to work on a package: you do not want to miss any issues. Later you may decide to relax things a bit. The foreign option tells Automake that this package will not follow the GNU Standards. GNU packages should always distribute additional files such as ChangeLog, AUTHORS, etc. We do not want automake to complain about these missing files in our small example.
The AC_PROG_CC
line causes the configure script to search for a C compiler and define the variable CC
with its name. The src/Makefile.in file generated by Automake uses the variable CC
to build hello, so when configure creates src/Makefile from src/Makefile.in, it will define CC
with the value it has found. If Automake is asked to create a Makefile.inthat uses CC
but configure.ac does not define it, it will suggest you add a call to AC_PROG_CC
.
The AC_CONFIG_HEADERS([config.h])
invocation causes the configure script to create a config.h file gathering ‘#define’s defined by other macros in configure.ac. In our case, theAC_INIT
macro already defined a few of them. Here is an excerpt of config.h after configure has run:
... /* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "bug-automake@gnu.org" /* Define to the full name and version of this package. */ #define PACKAGE_STRING "amhello 1.0" ...
As you probably noticed, src/main.c includes config.h so it can use PACKAGE_STRING
. In a real-world project, config.h can grow really big, with one ‘#define’ per feature probed on the system.
The AC_CONFIG_FILES
macro declares the list of files that configure should create from their *.in templates. Automake also scans this list to find the Makefile.am files it must process. (This is important to remember: when adding a new directory to your project, you should add its Makefile to this list, otherwise Automake will never process the newMakefile.am you wrote in that directory.)
Finally, the AC_OUTPUT
line is a closing command that actually produces the part of the script in charge of creating the files registered with AC_CONFIG_HEADERS
and AC_CONFIG_FILES
.
When starting a new project, we suggest you start with such a simple configure.ac, and gradually add the other tests it requires. The command autoscan can also suggest a few of the tests your package may need (see Using autoscan to Create configure.ac).
We now turn to src/Makefile.am. This file contains Automake instructions to build and install hello.
bin_PROGRAMS = hello hello_SOURCES = main.c
A Makefile.am has the same syntax as an ordinary Makefile. When automake processes a Makefile.am it copies the entire file into the output Makefile.in (that will be later turned intoMakefile by configure) but will react to certain variable definitions by generating some build rules and other variables. Often Makefile.ams contain only a list of variable definitions as above, but they can also contain other variable and rule definitions that automake will pass along without interpretation.
Variables that end with _PROGRAMS
are special variables that list programs that the resulting Makefile should build. In Automake speak, this _PROGRAMS
suffix is called a primary; Automake recognizes other primaries such as _SCRIPTS
, _DATA
, _LIBRARIES
, etc. corresponding to different types of files.
The ‘bin’ part of the bin_PROGRAMS
tells automake that the resulting programs should be installed in bindir. Recall that the GNU Build System uses a set of variables to denote destination directories and allow users to customize these locations (see Standard Directory Variables). Any such directory variable can be put in front of a primary (omitting the dir
suffix) to tell automake where to install the listed files.
Programs need to be built from source files, so for each program prog listed in a _PROGRAMS
variable, automake will look for another variable named prog_SOURCES
listing its source files. There may be more than one source file: they will all be compiled and linked together.
Automake also knows that source files need to be distributed when creating a tarball (unlike built programs). So a side-effect of this hello_SOURCES
declaration is that main.cwill be part of the tarball created by make dist
.
Finally here are some explanations regarding the top-level Makefile.am.
SUBDIRS = src dist_doc_DATA = README
SUBDIRS
is a special variable listing all directories that make should recurse into before processing the current directory. So this line is responsible for make buildingsrc/hello even though we run it from the top-level. This line also causes make install
to install src/hello before installing README (not that this order matters).
The line dist_doc_DATA = README
causes README to be distributed and installed in docdir. Files listed with the _DATA
primary are not automatically part of the tarball built withmake dist
, so we add the dist_
prefix so they get distributed. However, for README it would not have been necessary: automake automatically distributes any README file it encounters (the list of other files automatically distributed is presented by automake --help
). The only important effect of this second line is therefore to install READMEduring make install
.
原文地址:
http://www.gnu.org/s/hello/manual/automake/amhello-Explained.html
注意其中的对primary的解释。