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, one in each subdirectory of the package (the section called “Substitutions in Makefiles ”);
optionally, a C header file, the name of which is configurable, containing #define directives (the section called “Configuration Header Files ”);
a shell script called config.status that, when run, will recreate the files listed above (Chapter 15);
an optional shell script normally called config.cache (created when using configure -config-cache) that saves the results of running many of the tests (the section called “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 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 ---'
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 Chapter 6, for their descriptions. For most other features, you can use Autoconf template macros to produce custom checks; see Chapter 7, for information about them. For especially tricky or specialized features, configure.ac might need to contain some hand-crafted shell commands; see Chapter 11. The autoscan program can give you a good start in writing configure.ac (the section called “Using autoscanto 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.
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.
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])])
Voilagrave;, 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.
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 (the section called “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 (Chapter 6), 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