Autotools

Autotools Tutorial
Software Engineering Group 2
Sven Van Segbroeck

svsegbro@vub.ac.be
March 18, 2004
1 Introduction
1.1 What?
Autotools consists of the following 3 packages:
• Autoconf
• Automake
• Libtool
1.2 Why?
Some tasks that are simplified by Autotools:
• Building multidirectory software packages (better organisation of source
code)
• Automatic configuration
• Automatic makefile generation
• Support for test suites
• Automatic distribution building
• Shared libraries
1
1.3 Autotools as perceived by end-user
Let ”name-version”.tar.gz be an autoconfiguring package.
Typically you do something as follows to install it:
> tar -xvzf ”name-version”.tar.gz

> cd ”name-version”
> ./configure
> make
> make check (optionally)
> su
> make install
1.4 Autotools on developer’s side

Basically the developer writes ’configure.ac’ and ’Makefile.am’, and Auto-
tools does the rest.
Gnu Makefile.am
autoheader Gnu
automake
config.h.in
configure.ac Makefile.in
configure
config.h
Gnu Makefile Make

autoconf
Figure 1: General Overview
2
2 Autoconf
Autoconf is a tool for producing shell scripts that automatically configure soft-
ware source code packages to adapt to many kinds of UNIX-like systems. The
configuration scripts produced by Autoconf ( called ’configure’ ) are inde-
pendent of Autoconf when they are run, so their users do not need to have
Autoconf.
2.1 configure.ac
The file configure.ac contains invocations of the Autoconf macros that test the
system features your package needs or can use. Autoconf macros already exist to
check for many features. For most other features you can use Autoconf template
macros to produce custom checks ( see [2] chapter 6 p.71 ). For especially tricky
of specialized features ’configure.ac’ might need to contain some hand-crafted
shell commands ( see [2] chapter 10 p.113 ).
2.1.1 The Autoconf Language

The Autoconf language treats actual code the same as plain text. Therefore
literal strings are distinguished from text to be expanded by using quotation.
When calling macros that take arguments, there must not be any blank space
between the macro name and the open parenthesis. Arguments should be en-
closed within the M4 quote characters ’[’ and ’]’, and separated by commas.
Any leading spaces in arguments are ignored, unless they are quoted. You may
safely leave out quotes when the argument is simple text, but always quote
complex arguments such as other macro calls. This rule applies recursively for
every macro call, including macros called from other macros.
The rule of thumb is that whenever you expect macro expansion, expect quote
expansion. Therefore it’s a good idea to use double quoting for all literal string
arguments.
Some macros take optional arguments. You may just leave them empty, or use
’[]’,or simply omit the trailing commas.
It’s best to put each macro call on its own line in ’configure.ac’.
You can include comments in ’configure.ac’ files by starting them with the ’#
’.
2.1.2 Standard Layout

standard layout of ’configure.ac’:
Autoconf requirements
AC INIT(package,version,bug-report-address)
information on the package
checks for programs
checks for libraries
3
checks for header files
checks for types
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services
AC CONFIG FILES([file...])
AC OUTPUT
2.1.3 Existing Tests

see [2] chapter 5 p.35.
3 Automake
Automake is a tool for automatically generating ’Makefile.in’s from files called
’Makefile.am’. Each ’Makefile.am’ is basically a series of make variable def-
initions, with rules being thrown in occasionally. Generally there should be one
’Makefile.am’ per directory of a project.
Some provided make targets:

-make all
-make check
-make install
-make uninstall
-make clean
-make dist
-make distcheck
3.1 The Uniform Naming Scheme

Automake variables generally follow a uniform naming scheme that makes it
easy to decide how programs (and other derived objects) are built, and how
they are installed.
At make time, certain variables are used to determine which objects are to be
built. The variable names are made of several pieces which are concatenated
together.
The piece which tells automake what’s being built is commonly called the pri-
mary.
Current primary names:
• PROGRAMS
• LIBRARIES
4
• LISP
• PYTHON
• JAVA
• SCRIPTS
• DATA
• HEADERS
• MANS
• TEXINFOS
A different set of names is used to decide where the built objects should be in-
stalled. These names are prefixes to the primary which indicate which standard
directory should be used as installation directory. The standard directory names
are given in the GNU standards. Automake extends this list with pkglibdir,
pkgincludedir and pkgdatadir. These are the same as the non-’pkg’ versions,
but with ’@PACKAGE@’ appended. For instance, pkglibdir is defined as $
(libdir)/@PACKAGE@.
For each primary there is one additional variable named by prepending ’EX-
TRA ’ to the primary name. This variable is used to list objects which may or
may not be built, depending on what configure decides.
Note that the common ’dir’ suffix is left off when constructing the variable
names. Thus one writes ’bin PROGRAMS’ and not ’bindir PROGRAMS’.
Sometimes the standard directories are not enough. In particular it’s some-
times useful to install objects in a subdirectory of some predefined directory.
For instance:
htmldir = $ (prefix)/html
html DATA = automake.html
The special prefix ’noinst’ indicates that the objects in question should be
built but not installed at all. This is usually used for objects required to build
the rest of your package.
The special prefix ’check’ indicates that the objects in question should not be
built until the make check command is run. Those objects are not installed
either.
Some primaries also allow additional prefixes which control other aspects of au-
tomake’s behavior. The currently defined prefixes are ’dist ’,’nodist ’,’nobase ’.
See [3] section 9.4 p.33.
5
3.2 Recursing subdirectories
In packages with subdirectories, the top level ’Makefile.am’ must tell Au-
tomake which subdirectories are to be built. This is done via the SUBDIRS
variable.
The SUBDIRS variable holds a list of subdirectories in which building of various
sorts can occur. Many targets (e.g. all) in the generated ’Makefile’ will run
both locally and in all specified subdirectories. Note that the directories listed
in SUBDIRS are not required to contain ’Makefile.am’s; only ’Makefile’s (af-
ter configuration). This allows inclusion of libraries from packages which do not
use Automake (such as gettext).
In packages that use subdirectories, the top-level ’Makefile.am’ is often very
short. For instance:
EXTRA DIST = BUGS ChangeLog.0 README-alpha
SUBDIRS = doc intl po src tests
The directories mentioned in SUBDIRS must be direct children of the current

directory.
3.3 Building programs

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.
3.3.1 Defining program sources

In a directory containing source that gets build into a program the ’PRO-
GRAMS’ primary is used. For instance:
bin PROGRAMS = hello
Associated with each program are several assisting variables which are named
after the program. The variable hello SOURCES is used to specify which source
files get built into an executable.
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.
3.3.2 Linking the program

If you need to link against libraries that are not found by configure, you can
use LDADD to do so. This variable is used to specify additional objects or
libraries to link with; it’s inappropriate for specifying specific linker flags, you
should use AM LDFLAGS for this purpose.
Sometimes, multiple programs are built in one directory but do not share the
same linktime 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) to override the global LDADD. If this variable exists
6
for a given program, then that program is not linked using LDADD.
It’s 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.
3.3.3 Variables used when building a program

Some variable are inherited from Autoconf: CC, CFLAGS, CPPFLAGS, DEFS,
LDFLAGS, LIBS
There are some additional variables which Automake itself defines: AM CPPFLAGS,
INCLUDES, AM CFLAGS, COMPILE, AM LDFLAGS, LINK. Further in-
formation on them: see [3] section 9.6 p.36
Any package including C++ code must define the output variable ’CXX’ in ’con-
figure.ac’; the simplest way to do this is to use the AC PROG CXX macro.
A few additional variables are defined when a C++ source file is seen: CXX,
CXXFLAGS, AM CXXFLAGS, CXXCOMPILE, CXXLINK
3.4 Example
see [3] chapter 3 p.6
4 Example
1. see [1] section 1.3 and 1.4
2. see packages D. Vermeir
3. see CVS in directory ../sourcecoude/autotools
5 Libtool
Very often, one wants to build not only programs, but libraries, so that other
programs can benefit form the fruits of your labour. Ideally, one would like to
produce shared ( dynamically linked ) libraries, which can be used by multiple
programs without duplication on disk or in memory and can be updated inde-
pendently of the linked programs. Producing shared libraries portably can be
done easily by using Libtool.
References
[1] Learning the GNU development tools:
http://www.cs.ucsb.edu/ htang/gnubuild/tutorial.pdf
[2] Autoconf:
http://www.fsf.org/manual/manual.html
7
[3] Automake:
[4] Libtool:

Autotools

Uploaded by

Copyright:

Available Formats

Autotools

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autotools

Uploaded by

Copyright:

Available Formats

Autotools Tutorial

Software Engineering Group 2

Sven Van Segbroeck

> tar -xvzf ”name-version”.tar.gz

1.4 Autotools on developer’s side

Gnu Makefile Make

Figure 1: General Overview

2.1.1 The Autoconf Language

2.1.2 Standard Layout

2.1.3 Existing Tests

Some provided make targets:

3.1 The Uniform Naming Scheme

The directories mentioned in SUBDIRS must be direct children of the current

3.3 Building programs

3.3.1 Defining program sources

3.3.2 Linking the program

3.3.3 Variables used when building a program

You might also like