3. Making configure Scripts

The configuration scripts that Autoconf produces are by convention called configure. When run, configure creates several files, replacing configuration parameters in them with appropriate values. The files that configure creates are:

• - one or more `Makefile' files, usually one in each subdirectory of the package (see section Substitutions in Makefiles);
• - optionally, a C header file, the name of which is configurable, containing #define directives (see section Configuration Header Files);
• - a shell script called `config.status' that, when run, recreates the files listed above (see section config.status Invocation);
• - an optional shell script normally called `config.cache' (created when using `configure --config-cache') that saves the results of running many of the tests (see section Cache Files);
• - a file called `config.log' containing any messages produced by compilers, to help debugging if configure makes a mistake.

To create a configure script with Autoconf, you need to write an Autoconf input file `configure.ac' (or `configure.in') and run autoconf on it. If you write your own feature tests to supplement those that come with Autoconf, you might also write files called `aclocal.m4' and `acsite.m4'. If you use a C header file to contain #define directives, you might also run autoheader, and you can distribute the generated file `config.h.in' with the package.

Here is a diagram showing how the files that can be used in configuration are produced. Programs that are executed are suffixed by `*'. Optional files are enclosed in square brackets (`[]'). autoconf and autoheader also read the installed Autoconf macro files (by reading `autoconf.m4').

Files used in preparing a software package for distribution:

your source files --> [autoscan*] --> [configure.scan] --> configure.ac

configure.ac --.
               |   .------> autoconf* -----> configure
[aclocal.m4] --+---+
               |   `-----> [autoheader*] --> [config.h.in]
[acsite.m4] ---'

Makefile.in -------------------------------> Makefile.in

Files used in configuring a software package:

                       .-------------> [config.cache]
configure* ------------+-------------> config.log
                       |
[config.h.in] -.       v            .-> [config.h] -.
               +--> config.status* -+               +--> make*
Makefile.in ---'                    `-> Makefile ---'

3.1 Writing `configure.ac'

To produce a configure script for a software package, create a file called `configure.ac' that 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; see Existing Tests, for their descriptions. For most other features, you can use Autoconf template macros to produce custom checks; see Writing Tests, for information about them. For especially tricky or specialized features, `configure.ac' might need to contain some hand-crafted shell commands; see Portable Shell Programming. The autoscan program can give you a good start in writing `configure.ac' (see section Using autoscan to Create `configure.ac', for more information).

Previous versions of Autoconf promoted the name `configure.in', which is somewhat ambiguous (the tool needed to process this file is not described by its extension), and introduces a slight confusion with `config.h.in' and so on (for which `.in' means "to be processed by configure"). Using `configure.ac' is now preferred.

3.1.1 A Shell Script Compiler

Just as for any other computer language, in order to properly program `configure.ac' in Autoconf you must understand what problem the language tries to address and how it does so.

The problem Autoconf addresses is that the world is a mess. After all, you are using Autoconf in order to have your package compile easily on all sorts of different systems, some of them being extremely hostile. Autoconf itself bears the price for these differences: configure must run on all those systems, and thus configure must limit itself to their lowest common denominator of features.

Naturally, you might then think of shell scripts; who needs autoconf? A set of properly written shell functions is enough to make it easy to write configure scripts by hand. Sigh! Unfortunately, even in 2008, where shells without any function support are far and few between, there are pitfalls to avoid when making use of them. Also, finding a Bourne shell that accepts shell functions is not trivial, even though there is almost always one on interesting porting targets.

So, what is really needed is some kind of compiler, autoconf, that takes an Autoconf program, `configure.ac', and transforms it into a portable shell script, configure.

How does autoconf perform this task?

There are two obvious possibilities: creating a brand new language or extending an existing one. The former option is attractive: all sorts of optimizations could easily be implemented in the compiler and many rigorous checks could be performed on the Autoconf program (e.g., rejecting any non-portable construct). Alternatively, you can extend an existing language, such as the sh (Bourne shell) language.

Autoconf does the latter: it is a layer on top of sh. It was therefore most convenient to implement autoconf as a macro expander: a program that repeatedly performs macro expansions on text input, replacing macro calls with macro bodies and producing a pure sh script in the end. Instead of implementing a dedicated Autoconf macro expander, it is natural to use an existing general-purpose macro language, such as M4, and implement the extensions as a set of M4 macros.

3.1.2 The Autoconf Language

The Autoconf language differs from many other computer languages because it treats actual code the same as plain text. Whereas in C, for instance, data and instructions have different syntactic status, in Autoconf their status is rigorously the same. Therefore, we need a means to distinguish literal strings from text to be expanded: quotation.

When calling macros that take arguments, there must not be any white space between the macro name and the open parenthesis. Arguments should be enclosed within the M4 quote characters `[' and `]', and be separated by commas. Any leading blanks or newlines in arguments are ignored, unless they are quoted. You should always quote an argument that might contain a macro name, comma, parenthesis, or a leading blank or newline. This rule applies recursively for every macro call, including macros called from other macros.

For instance:

AC_CHECK_HEADER([stdio.h],
                [AC_DEFINE([HAVE_STDIO_H], [1],
                   [Define to 1 if you have <stdio.h>.])],
                [AC_MSG_ERROR([Sorry, can't do anything for you])])

is quoted properly. You may safely simplify its quotation to:

AC_CHECK_HEADER([stdio.h],
                [AC_DEFINE([HAVE_STDIO_H], 1,
                   [Define to 1 if you have <stdio.h>.])],
                [AC_MSG_ERROR([Sorry, can't do anything for you])])

because `1' cannot contain a macro call. Here, the argument of AC_MSG_ERROR must be quoted; otherwise, its comma would be interpreted as an argument separator. Also, the second and third arguments of `AC_CHECK_HEADER' must be quoted, since they contain macro calls. The three arguments `HAVE_STDIO_H', `stdio.h', and `Define to 1 if you have <stdio.h>.' do not need quoting, but if you unwisely defined a macro with a name like `Define' or `stdio' then they would need quoting. Cautious Autoconf users would keep the quotes, but many Autoconf users find such precautions annoying, and would rewrite the example as follows:

AC_CHECK_HEADER(stdio.h,
                [AC_DEFINE(HAVE_STDIO_H, 1,
                   [Define to 1 if you have <stdio.h>.])],
                [AC_MSG_ERROR([Sorry, can't do anything for you])])

This is safe, so long as you adopt good naming conventions and do not define macros with names like `HAVE_STDIO_H', `stdio', or `h'. Though it is also safe here to omit the quotes around `Define to 1 if you have <stdio.h>.' this is not recommended, as message strings are more likely to inadvertently contain commas.

The following example is wrong and dangerous, as it is underquoted:

AC_CHECK_HEADER(stdio.h,
                AC_DEFINE(HAVE_STDIO_H, 1,
                   Define to 1 if you have <stdio.h>.),
                AC_MSG_ERROR([Sorry, can't do anything for you]))

In other cases, you may have to use text that also resembles a macro call. You must quote that text even when it is not passed as a macro argument. For example, these two approaches in `configure.ac' (quoting just the potential problems, or quoting the entire line) will protect your script in case autoconf ever adds a macro AC_DC:

echo "Hard rock was here!  --[AC_DC]"
[echo "Hard rock was here!  --AC_DC"]

which results in this text in `configure':

echo "Hard rock was here!  --AC_DC"
echo "Hard rock was here!  --AC_DC"

When you use the same text in a macro argument, you must therefore have an extra quotation level (since one is stripped away by the macro substitution). In general, then, it is a good idea to use double quoting for all literal string arguments, either around just the problematic portions, or over the entire argument:

AC_MSG_WARN([[AC_DC] stinks  --Iron Maiden])
AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])

However, the above example triggers a warning about a possibly unexpanded macro when running autoconf, because it collides with the namespace of macros reserved for the Autoconf language. To be really safe, you can use additional escaping (either a quadrigraph, or creative shell constructs) to silence that particular warning:

echo "Hard rock was here!  --AC""_DC"
AC_MSG_WARN([[AC@&t@_DC stinks  --Iron Maiden]])

You are now able to understand one of the constructs of Autoconf that has been continually misunderstood.... The rule of thumb is that whenever you expect macro expansion, expect quote expansion; i.e., expect one level of quotes to be lost. For instance:

AC_COMPILE_IFELSE([char b[10];], [], [AC_MSG_ERROR([you lose])])

is incorrect: here, the first argument of AC_COMPILE_IFELSE is `char b[10];' and is expanded once, which results in `char b10;'. (There was an idiom common in Autoconf's past to address this issue via the M4 changequote primitive, but do not use it!) Let's take a closer look: the author meant the first argument to be understood as a literal, and therefore it must be quoted twice:

AC_COMPILE_IFELSE([[char b[10];]], [], [AC_MSG_ERROR([you lose])])

Voilà, you actually produce `char b[10];' this time!

On the other hand, descriptions (e.g., the last parameter of AC_DEFINE or AS_HELP_STRING) are not literals--they are subject to line breaking, for example--and should not be double quoted. Even if these descriptions are short and are not actually broken, double quoting them yields weird results.

Some macros take optional arguments, which this documentation represents as [arg]just leave them empty, or use `[]' to make the emptiness of the argument explicit, or you may simply omit the trailing commas. The three lines below are equivalent:

AC_CHECK_HEADERS([stdio.h], [], [], [])
AC_CHECK_HEADERS([stdio.h],,,)
AC_CHECK_HEADERS([stdio.h])

It is best to put each macro call on its own line in `configure.ac'. Most of the macros don't add extra newlines; they rely on the newline after the macro call to terminate the commands. This approach makes the generated configure script a little easier to read by not inserting lots of blank lines. It is generally safe to set shell variables on the same line as a macro call, because the shell allows assignments without intervening newlines.

You can include comments in `configure.ac' files by starting them with the `#'. For example, it is helpful to begin `configure.ac' files with a line like this:

# Process this file with autoconf to produce a configure script.

3.1.3 Standard `configure.ac' Layout

The order in which `configure.ac' calls the Autoconf macros is not important, with a few exceptions. Every `configure.ac' must contain a call to AC_INIT before the checks, and a call to AC_OUTPUT at the end (see section Outputting Files). Additionally, some macros rely on other macros having been called first, because they check previously set values of some variables to decide what to do. These macros are noted in the individual descriptions (see section Existing Tests), and they also warn you when configure is created if they are called out of order.

To encourage consistency, here is a suggested order for calling the Autoconf macros. Generally speaking, the things near the end of this list are those that could depend on things earlier in it. For example, library functions could be affected by types and libraries.

Autoconf requirements
AC_INIT(package, version, bug-report-address)
information on the package
checks for programs
checks for libraries
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

3.2 Using autoscan to Create `configure.ac'

The autoscan program can help you create and/or maintain a `configure.ac' file for a software package. autoscan examines source files in the directory tree rooted at a directory given as a command line argument, or the current directory if none is given. It searches the source files for common portability problems and creates a file `configure.scan' which is a preliminary `configure.ac' for that package, and checks a possibly existing `configure.ac' for completeness.

When using autoscan to create a `configure.ac', you should manually examine `configure.scan' before renaming it to `configure.ac'; it probably needs some adjustments. Occasionally, autoscan outputs a macro in the wrong order relative to another macro, so that autoconf produces a warning; you need to move such macros manually. Also, if you want the package to use a configuration header file, you must add a call to AC_CONFIG_HEADERS (see section Configuration Header Files). You might also have to change or add some #if directives to your program in order to make it work with Autoconf (see section Using ifnames to List Conditionals, for information about a program that can help with that job).

When using autoscan to maintain a `configure.ac', simply consider adding its suggestions. The file `autoscan.log' contains detailed information on why a macro is requested.

autoscan uses several data files (installed along with Autoconf) to determine which macros to output when it finds particular symbols in a package's source files. These data files all have the same format: each line consists of a symbol, one or more blanks, and the Autoconf macro to output if that symbol is encountered. Lines starting with `#' are comments.

autoscan accepts the following options:

`--help'

`-h'

Print a summary of the command line options and exit.

`--version'

`-V'

Print the version number of Autoconf and exit.

`--verbose'

`-v'

Print the names of the files it examines and the potentially interesting symbols it finds in them. This output can be voluminous.

`--debug'

`-d'

Don't remove temporary files.

`--include=dir'

`-I dir'

Append dir to the include path. Multiple invocations accumulate.

`--prepend-include=dir'

`-B dir'

Prepend dir to the include path. Multiple invocations accumulate.

3.3 Using ifnames to List Conditionals

ifnames can help you write `configure.ac' for a software package. It prints the identifiers that the package already uses in C preprocessor conditionals. If a package has already been set up to have some portability, ifnames can thus help you figure out what its configure needs to check for. It may help fill in some gaps in a `configure.ac' generated by autoscan (see section Using autoscan to Create `configure.ac').

ifnames scans all of the C source files named on the command line (or the standard input, if none are given) and writes to the standard output a sorted list of all the identifiers that appear in those files in #if, #elif, #ifdef, or #ifndef directives. It prints each identifier on a line, followed by a space-separated list of the files in which that identifier occurs.

ifnames accepts the following options:

`--help'

`-h'

Print a summary of the command line options and exit.

`--version'

`-V'

Print the version number of Autoconf and exit.

3.4 Using autoconf to Create configure

To create configure from `configure.ac', run the autoconf program with no arguments. autoconf processes `configure.ac' with the M4 macro processor, using the Autoconf macros. If you give autoconf an argument, it reads that file instead of `configure.ac' and writes the configuration script to the standard output instead of to configure. If you give autoconf the argument `-', it reads from the standard input instead of `configure.ac' and writes the configuration script to the standard output.

The Autoconf macros are defined in several files. Some of the files are distributed with Autoconf; autoconf reads them first. Then it looks for the optional file `acsite.m4' in the directory that contains the distributed Autoconf macro files, and for the optional file `aclocal.m4' in the current directory. Those files can contain your site's or the package's own Autoconf macro definitions (see section Writing Autoconf Macros, for more information). If a macro is defined in more than one of the files that autoconf reads, the last definition it reads overrides the earlier ones.

autoconf accepts the following options:

`--help'

`-h'

Print a summary of the command line options and exit.

`--version'

`-V'

Print the version number of Autoconf and exit.

`--verbose'

`-v'

Report processing steps.

`--debug'

`-d'

Don't remove the temporary files.

`--force'

`-f'

Remake `configure' even if newer than its input files.

`--include=dir'

`-I dir'

Append dir to the include path. Multiple invocations accumulate.

`--prepend-include=dir'

`-B dir'

Prepend dir to the include path. Multiple invocations accumulate.

`--output=file'

`-o file'

Save output (script or trace) to file. The file `-' stands for the standard output.

`--warnings=category'

`-W category'

Report the warnings related to category (which can actually be a comma separated list). See section Reporting Messages, macro AC_DIAGNOSE, for a comprehensive list of categories. Special values include:

`all'

report all the warnings

`none'

report none

`error'

treats warnings as errors

`no-category'

disable warnings falling into category

Warnings about `syntax' are enabled by default, and the environment variable WARNINGS, a comma separated list of categories, is honored as well. Passing `-W category' actually behaves as if you had passed `--warnings syntax,$WARNINGS,category'. To disable the defaults and WARNINGS, and then enable warnings about obsolete constructs, use `-W none,obsolete'.

Because autoconf uses autom4te behind the scenes, it displays a back trace for errors, but not for warnings; if you want them, just pass `-W error'. See section Invoking autom4te, for some examples.

`--trace=macro[:format]'

`-t macro[:format]'

Do not create the configure script, but list the calls to macro according to the format. Multiple `--trace' arguments can be used to list several macros. Multiple `--trace' arguments for a single macro are not cumulative; instead, you should just make format as long as needed.

The format is a regular string, with newlines if desired, and several special escape codes. It defaults to `$f:$l:$n:$%'; see Invoking autom4te, for details on the format.

`--initialization'

`-i'

By default, `--trace' does not trace the initialization of the Autoconf macros (typically the AC_DEFUN definitions). This results in a noticeable speedup, but can be disabled by this option.

It is often necessary to check the content of a `configure.ac' file, but parsing it yourself is extremely fragile and error-prone. It is suggested that you rely upon `--trace' to scan `configure.ac'. For instance, to find the list of variables that are substituted, use:

$ autoconf -t AC_SUBST
configure.ac:2:AC_SUBST:ECHO_C
configure.ac:2:AC_SUBST:ECHO_N
configure.ac:2:AC_SUBST:ECHO_T
More traces deleted

The example below highlights the difference between `$@', `$*', and `$%'.

$ cat configure.ac
AC_DEFINE(This, is, [an
[example]])
$ autoconf -t 'AC_DEFINE:@: $@
*: $*
%: $%'
@: [This],[is],[an
[example]]
*: This,is,an
[example]
%: This:is:an [example]

The format gives you a lot of freedom:

$ autoconf -t 'AC_SUBST:$$ac_subst{"$1"} = "$f:$l";'
$ac_subst{"ECHO_C"} = "configure.ac:2";
$ac_subst{"ECHO_N"} = "configure.ac:2";
$ac_subst{"ECHO_T"} = "configure.ac:2";
More traces deleted

A long separator can be used to improve the readability of complex structures, and to ease their parsing (for instance when no single character is suitable as a separator):

$ autoconf -t 'AM_MISSING_PROG:${|:::::|}*'
ACLOCAL|:::::|aclocal|:::::|$missing_dir
AUTOCONF|:::::|autoconf|:::::|$missing_dir
AUTOMAKE|:::::|automake|:::::|$missing_dir
More traces deleted

3.5 Using autoreconf to Update configure Scripts

Installing the various components of the GNU Build System can be tedious: running autopoint for Gettext, automake for `Makefile.in' etc. in each directory. It may be needed either because some tools such as automake have been updated on your system, or because some of the sources such as `configure.ac' have been updated, or finally, simply in order to install the GNU Build System in a fresh tree.

autoreconf runs autoconf, autoheader, aclocal, automake, libtoolize, and autopoint (when appropriate) repeatedly to update the GNU Build System in the specified directories and their subdirectories (see section Configuring Other Packages in Subdirectories). By default, it only remakes those files that are older than their sources. The environment variables AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL, AUTOPOINT, LIBTOOLIZE, M4, and MAKE may be used to override the invocation of the respective tools.

If you install a new version of some tool, you can make autoreconf remake all of the files by giving it the `--force' option.

See section Automatic Remaking, for Make rules to automatically rebuild configure scripts when their source files change. That method handles the timestamps of configuration header templates properly, but does not pass `--autoconf-dir=dir' or `--localdir=dir'.

Gettext supplies the autopoint command to add translation infrastructure to a source package. If you use autopoint, your `configure.ac' should invoke both AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION(gettext-version). See (gettext)autopoint Invocation section `Invoking the autopoint Program' in GNU gettext utilities, for further details.

autoreconf accepts the following options:

`--help'

`-h'

Print a summary of the command line options and exit.

`--version'

`-V'

Print the version number of Autoconf and exit.

`--verbose'

`-V'

Print the name of each directory autoreconf examines and the commands it runs. If given two or more times, pass `--verbose' to subordinate tools that support it.

`--debug'

`-d'

Don't remove the temporary files.

`--force'

`-f'

Remake even `configure' scripts and configuration headers that are newer than their input files (`configure.ac' and, if present, `aclocal.m4').

`--install'

`-i'

Install the missing auxiliary files in the package. By default, files are copied; this can be changed with `--symlink'.

If deemed appropriate, this option triggers calls to `automake --add-missing', `libtoolize', `autopoint', etc.

`--no-recursive'

Do not rebuild files in subdirectories to configure (see Configuring Other Packages in Subdirectories, macro AC_CONFIG_SUBDIRS).

`--symlink'

`-s'

When used with `--install', install symbolic links to the missing auxiliary files instead of copying them.

`--make'

`-m'

When the directories were configured, update the configuration by running `./config.status --recheck && ./config.status', and then run `make'.

`--include=dir'

`-I dir'

Append dir to the include path. Multiple invocations accumulate. Passed on to aclocal, autoconf and autoheader internally.

`--prepend-include=dir'

`-B dir'

Prepend dir to the include path. Multiple invocations accumulate. Passed on to autoconf and autoheader internally.

`--warnings=category'

`-W category'

Report the warnings related to category (which can actually be a comma separated list).

`cross'

related to cross compilation issues.

`obsolete'

report the uses of obsolete constructs.

`portability'

portability issues

`syntax'

dubious syntactic constructs.

`all'

report all the warnings

`none'

report none

`error'

treats warnings as errors

`no-category'

disable warnings falling into category

Warnings about `syntax' are enabled by default, and the environment variable WARNINGS, a comma separated list of categories, is honored as well. Passing `-W category' actually behaves as if you had passed `--warnings syntax,$WARNINGS,category'. To disable the defaults and WARNINGS, and then enable warnings about obsolete constructs, use `-W none,obsolete'.

If you want autoreconf to pass flags that are not listed here on to aclocal, set ACLOCAL_AMFLAGS in your `Makefile.am'. Due to a limitation in the Autoconf implementation these flags currently must be set on a single line in `Makefile.am', without any backslash-newlines.

This document was generated on January, 20 2010 using texi2html 1.76.