'test "X$variable" = X'mean?
in configure.ac scripts?
This document aims to answer the most frequently asked questions about the GNU Autotools (Autoconf, Automake, and Libtool).
The master location of this document is available online at http://www.gnu.org/software/automake/faq/autotools-faq.html, generated from http://www.gnu.org/software/automake/faq/autotools-faq.texi.
Copyright © 2011 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License.”
All example code shown in this FAQ is in the public domain.
The name GNU Autotools commonly refers to the software packages Autoconf, Automake, and Libtool. They consist of a number of programs used by developers, among them autoreconf, autoconf, autoheader, autoscan (which come from the Autoconf package), aclocal and automake (which come from the Automake package), and libtoolize (from the Libtool package).
Together, they make up the GNU Build System.
Often, the following tools are used at the same time: gnulib-tool (from the gnulib package), gettextize and autopoint (from the gettext package).
Under the hood, the autotools use a helper script named autom4te which itself calls out to GNU M4.
The home page for GNU Autoconf. The home page for GNU Automake. The home page for GNU Libtool. The home page for GNU gnulib.
The tools have manuals, see Where is the official documentation?, and also individual FAQ chapters in the manual: see the Autoconf FAQ, see the Automake FAQ, see the Libtool FAQ.
Beside, there are a lot of Tutorials.
Usually, from the software distribution of your system. But you can also install them yourself, if there is a newer release available. If you build them yourself, it is recommended to install them all under the same prefix (see How can I install software below my home directory?).
The most recent stable releases can be found here:
http://ftp.gnu.org/gnu/autoconf/ http://ftp.gnu.org/gnu/automake/ http://ftp.gnu.org/gnu/libtool/
Development is done with Git source code management. A wiki page on Savannah documents how to use Git. The development versions of the Autotools can be found here:
http://savannah.gnu.org/git/?group=autoconf http://savannah.gnu.org/git/?group=automake http://savannah.gnu.org/git/?group=libtool http://savannah.gnu.org/git/?group=gnulib
Nightly snapshot tarballs of the Libtool sources are linked from the Libtool home page.
Simply write an email to the email@example.com mailing list. You do not need to be subscribed in order to write there. Past discussions can be found in the list archives.
If you like, you can send a patch against the source of the current version of the FAQ, written in Texinfo.
Each of the tools has separate bug reporting lists and list archives:
If you are unsure where to write to, choose one of the lists. It is not a big problem if you choose the wrong one, but please do not post your report to multiple lists in several separate mails.
TODO: Compare with CMake, waf, scons, ...
Alexandre Duret-Lutz' Autotools Tutorial, a very long and detailed tutorial in presentation form, also has a long list of other online tutorials and online Autotools resources.
The Autotools Introduction chapter of the Automake manual is a shortened version of Alexandre's tutorial.
All you should really know about Autoconf and Automake, a very short and concise tutorial from Paolo Bonzini.
Autotools Mythbuster, a longer guide also explaining some newer features, from Diego E. “Flameeyes” Pettenò.
Autotools: a practitioner's guide to Autoconf Automake and Libtool is a book introducing Autotools, from John Calcote.
The Goat Book or Autobook, officially titled “GNU Autoconf, Automake, and Libtool”, is a printed and online introduction into all three tools, from 2000, written by Gary V. Vaughan, Ben Elliston, Tom Tromey, and Ian Lance Taylor.
There are many more online tutorials and resources, especially for some specific build environments.
Example packages can be found here:
A Small Hello World Example with Automake in the Automake manual.
GNU hello, the (not so small) example package using all kinds of GNU infrastructure.
Each of the tools has a separate manual:
The Autoconf Manual The Automake Manual The Libtool Manual The gnulib Manual
If the Autotools are not installed on your system, or the installed versions are too old, and you do not have the rights to install or update them globally, then you can install them under your home directory as follows:
# Assume we want to install them below $HOME/local. myprefix=$HOME/local # Ensure the tools are accessible from PATH. # It is advisable to set this also in ~/.profile, for development. PATH=$myprefix/bin:$PATH export PATH # Do the following in a scratch directory. wget http://ftp.gnu.org/gnu/m4/m4-1.4.14.tar.gz wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.64.tar.gz wget http://ftp.gnu.org/gnu/automake/automake-1.11.1.tar.gz wget http://ftp.gnu.org/gnu/libtool/libtool-2.4.tar.gz gzip -dc m4-1.4.14.tar.gz | tar xvf - gzip -dc autoconf-2.64.tar.gz | tar xvf - gzip -dc automake-1.11.1.tar.gz | tar xvf - gzip -dc libtool-2.4.tar.gz | tar xvf - cd m4-1.4.14 ./configure -C --prefix=$myprefix && make && make install cd ../autoconf-2.64 ./configure -C --prefix=$myprefix && make && make install cd ../automake-1.11.1 ./configure -C --prefix=$myprefix && make && make install cd ../libtool-2.4 ./configure -C --prefix=$myprefix && make && make install # If everything succeeded, you can delete the scratch directory again.
usually: call autotools commands to copy and generate a number of files. Often just autoreconf -vi.
gnulib provides a very elaborate bootstrap script, see VCS Issues, see Modified imports.
The name bootstrap is preferred over ‘autogen.sh’ as there also exists an independent software package named AutoGen.
Generated on the developer system:
#defines, serves as template for the config.h file.
Installed from Autotools files:
Generated on the user system (the one running configure) in the build directory tree (the one where configure is run from):
TODO: link to the various drawings in the manuals,
Making configure Scripts
It can get even more complicated:
TODO: link to the nice online images?
What do I need to do when I want to add a sub/foo/Makefile.am file to an existing project (in a recursive Makefile setup)?
In general, it takes three steps:
## sub/Makefile.am SUBDIRS = ... SUBDIRS += foo
or add sub/foo to the ‘SUBDIRS’ variable in the toplevel Makefile.am if there is no intermediate sub/Makefile.am (see Subdirectories).
AC_CONFIG_FILES([sub/foo/Makefile])to the configure.ac file (see Requirements).
A few large package trees use more than one configure.ac file, i.e., they contain subpackages. In this case, all file names above are meant relative to the nearest higher-up configure.ac file (see Subpackages).
Then, rerunning make in the build directory should do the right thing unless you have rebuild rules disabled (see maintainer-mode); alternatively, run autoreconf -v in the toplevel source directory. See amhello Explained, for a small but complete example package.
In a nonrecursive Makefile project, depending on local convention, instead of the above three steps you would probably write a fragment file to be included in the toplevel Makefile.am:
## toplevel Makefile.am ... include sub/foo/fragment.am
Note that in this case you also need to use the relative subdirectory prefixes in file names used inside the fragment file (see Alternative).
AC_SUBST, see Setting Output Variables,
see General Operation.
AC_DEFINE, see Defining Symbols.
setting in Makefile.am
AUTOMAKE_OPTIONS = -Wno-override -Wno-syntax
./configure --prefix="$HOME/local" make make install
As user of an autotooled package:
./configure CPPFLAGS="-I$somewhere/include" LDFLAGS="-L$somewhere/lib"
As configure.ac author:
gnulib module ‘havelib’: Searching for Libraries
'test "X$variable" = X'mean?
Weird way of writing
test -z "$variable"
that does not confuse the test builtins from old shells
$variable is ‘=’ or
(see Limitations of Builtins).
in configure.ac scripts?
either quote them by using more brackets, or use Quadrigraphs
portable encoding of static and shared library names and dependencies.
removing usually only works OK if done in directories which the runtime
linker searches by default anyway (otherwise you might need to set
LD_LIBRARY_PATH or an equivalent variable) and only on systems
where the runtime linker loads indirect library dependencies automatically
(includes GNU/Linux, GNU, Solaris).
somehow the output section of libtool.m4 does not get emitted into config.status. There has been an incompatibility in Autoconf's M4Sugar macros, and Libtool relied on one of those, not taking measures. It should work to use a new enough Autoconf.
Use a cache file when developing: configure -C aka. configure --config-cache (see Cache Files).
Install a config.site file which presets common test results (see Site Defaults).
Build in parallel: make -jn, with n greater than 1.
As a developer: ensure your project parallelizes well, e.g., by using nonrecursive makefiles.
pass both --host and --build to configure
either: very early after
(see Initializing configure),
ac_configure_args, but note quoting rules: the whole thing
is evaluated by the shell later:
eval configure "$ac_configure_args"
Here's a detailed explanation: Where to stick config.h.
If you absolutely need to use
#defines computed from
configure in installed headers:
AC_CONFIG_HEADERS. autoheader will only generate a header template for the first argument. see Header Templates.
AX_PREFIX_CONFIG_Hmacro from The Autoconf Macro Archive.