| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
#define directives (see section 4.8 Configuration Header Files);
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 will 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' What to put in an Autoconf input file 3.2 Using autoscanto Create `configure.ac'Semi-automatic `configure.ac' writing 3.3 Using ifnamesto List ConditionalsListing the conditionals in source code 3.4 Using autoconfto CreateconfigureHow to create configuration scripts 3.5 Using autoreconfto UpdateconfigureScriptsRemaking multiple configurescripts
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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
5. Existing Tests, for their descriptions. For most other features,
you can use Autoconf template macros to produce custom checks; see
6. Writing Tests, for information about them. For especially tricky
or specialized features, `configure.ac' might need to contain some
hand-crafted shell commands; see 10. Portable Shell Programming. The
autoscan program can give you a good start in writing
`configure.ac' (see section 3.2 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 produce 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 Autoconf as solution of a problem 3.1.2 The Autoconf Language Programming in Autoconf 3.1.3 Standard `configure.ac' Layout Standard organization of configure.ac
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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, shell functions do not belong to the least common
denominator; therefore, where you would like to define a function and
use it ten times, you would instead need to copy its body ten times.
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 very 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Autoconf language is very different from many other computer languages because it treats actual code the same as plain text. Whereas in C, for instance, data and instructions have very 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 blank 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 spaces in arguments are ignored, unless they are quoted. You may safely leave out the 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.
For instance:
AC_CHECK_HEADER([stdio.h],
[AC_DEFINE([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)],
[AC_MSG_ERROR([Sorry, can't do anything for you])])
|
Notice that the argument of AC_MSG_ERROR is still quoted;
otherwise, its comma would have been interpreted as an argument separator.
The following example is wrong and dangerous, as it is underquoted:
AC_CHECK_HEADER(stdio.h,
AC_DEFINE(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:
echo "Hard rock was here! --[AC_DC]" |
which will result in
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:
AC_MSG_WARN([[AC_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 will be 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!
The careful reader will notice that, according to these guidelines, the
"properly" quoted AC_CHECK_HEADER example above is actually
lacking three pairs of quotes! Nevertheless, for the sake of readability,
double quotation of literals is used only where needed in this manual.
Some macros take optional arguments, which this documentation represents as [arg] (not to be confused with the quote characters). You may 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. |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 4.4 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 5. 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 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 will probably need 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 4.8 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 3.3 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' will
contain 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, whitespace, and the Autoconf macro to
output if that symbol is encountered. Lines starting with `#' are
comments.
autoscan accepts the following options:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 3.2 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:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 9. 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:
AC_DIAGNOSE, for a comprehensive list of categories. Special
values include:
Warnings about `syntax' are enabled by default, and the environment
variable WARNINGS, a comma separated list of categories, is
honored. autoconf -W category will actually
behave as if you had run:
autoconf --warnings=syntax,$WARNINGS,category |
If you want to disable autoconf's defaults and WARNINGS,
but (for example) enable the warnings about obsolete constructs, you
would use `-W none,obsolete'.
autoconf displays a back trace for errors, but not for
warnings; if you want them, just pass `-W error'. For instance,
on this `configure.ac':
AC_DEFUN([INNER], [AC_TRY_RUN([exit (0)])]) AC_DEFUN([OUTER], [INNER]) AC_INIT OUTER |
you get:
$ autoconf -Wcross configure.ac:8: warning: AC_TRY_RUN called without default \ to allow cross compiling $ autoconf -Wcross,error configure.ac:8: error: AC_TRY_RUN called without default \ to allow cross compiling acgeneral.m4:3044: AC_TRY_RUN is expanded from... configure.ac:2: INNER is expanded from... configure.ac:5: OUTER is expanded from... configure.ac:8: the top level |
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 below for details on the format.
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'.
The format of `--trace' can use the following special escapes:
The escape `$%' produces single-line trace outputs (unless you put newlines in the `separator'), while `$@' and `$*' do not.
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 its 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
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
autoreconf to Update configure Scripts
Installing the various components of the GNU Build System can be
tedious: running gettextize, automake 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.
It runs autoconf, autoheader, aclocal,
automake, libtoolize, and gettextize (when
appropriate) repeatedly to update the GNU Build System in specified
directories, and their subdirectories (see section 4.11 Configuring Other Packages in Subdirectories). By
default, it only remakes those files that are older than their sources.
If you install a new version of some tools, you can make
autoreconf remake all of the files by giving it the
`--force' option.
See section 4.7.4 Automatic Remaking, for `Makefile' rules to automatically
remake 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'.
autoreconf accepts the following options:
autoreconf runs
autoconf (and autoheader, if appropriate).
--add-missing in automake.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |