Autoconf: Creating Automatic Configuration Scripts, by David MacKenzie. This file documents the GNU Autoconf package for creating scripts to configure source code packages using templates and an `m4' macro package. Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation. This file documents the GNU Autoconf package for creating scripts to configure source code packages using templates and the GNU M4 macro package. This is edition 2.52, for Autoconf version 2.52. Introduction ************ A physicist, an engineer, and a computer scientist were discussing the nature of God. "Surely a Physicist," said the physicist, "because early in the Creation, God made Light; and you know, Maxwell's equations, the dual nature of electromagnetic waves, the relativistic consequences..." "An Engineer!," said the engineer, "because before making Light, God split the Chaos into Land and Water; it takes a hell of an engineer to handle that big amount of mud, and orderly separation of solids from liquids..." The computer scientist shouted: "And the Chaos, where do you think it was coming from, hmm?" --Anonymous Autoconf is a tool for producing shell scripts that automatically configure software source code packages to adapt to many kinds of UNIX-like systems. The configuration scripts produced by Autoconf are independent of Autoconf when they are run, so their users do not need to have Autoconf. The configuration scripts produced by Autoconf require no manual user intervention when run; they do not normally even need an argument specifying the system type. Instead, they individually test for the presence of each feature that the software package they are for might need. (Before each check, they print a one-line message stating what they are checking for, so the user doesn't get too bored while waiting for the script to finish.) As a result, they deal well with systems that are hybrids or customized from the more common UNIX variants. There is no need to maintain files that list the features supported by each release of each variant of UNIX. For each software package that Autoconf is used with, it creates a configuration script from a template file that lists the system features that the package needs or can use. After the shell code to recognize and respond to a system feature has been written, Autoconf allows it to be shared by many software packages that can use (or need) that feature. If it later turns out that the shell code needs adjustment for some reason, it needs to be changed in only one place; all of the configuration scripts can be regenerated automatically to take advantage of the updated code. The Metaconfig package is similar in purpose to Autoconf, but the scripts it produces require manual user intervention, which is quite inconvenient when configuring large source trees. Unlike Metaconfig scripts, Autoconf scripts can support cross-compiling, if some care is taken in writing them. Autoconf does not solve all problems related to making portable software packages--for a more complete solution, it should be used in concert with other GNU build tools like Automake and Libtool. These other tools take on jobs like the creation of a portable, recursive `Makefile' with all of the standard targets, linking of shared libraries, and so on. *Note The GNU build system::, for more information. Autoconf imposes some restrictions on the names of macros used with `#if' in C programs (*note Preprocessor Symbol Index::.). Autoconf requires GNU M4 in order to generate the scripts. It uses features that some UNIX versions of M4, including GNU M4 1.3, do not have. You must use version 1.4 or later of GNU M4. *Note Autoconf 1::, for information about upgrading from version 1. *Note History::, for the story of Autoconf's development. *Note Questions::, for answers to some common questions about Autoconf. See the Autoconf web page(1) for up-to-date information, details on the mailing lists, pointers to a list of known bugs, etc. Mail suggestions to the Autoconf mailing list . Bug reports should be preferably submitted to the Autoconf Gnats database(2), or sent to the Autoconf Bugs mailing list . If possible, first check that your bug is not already solved in current development versions, and that it has not been reported yet. Be sure to include all the needed information and a short `configure.ac' that demonstrates the problem. Autoconf's development tree is accessible via CVS; see the Autoconf web page for details. There is also a CVSweb interface to the Autoconf development tree(3). Patches relative to the current CVS version can be sent for review to the Autoconf Patches mailing list . Because of its mission, Autoconf includes only a set of often-used macros that have already demonstrated their usefulness. Nevertheless, if you wish to share your macros, or find existing ones, see the Autoconf Macro Archive(4), which is kindly run by Peter Simons . ---------- Footnotes ---------- (1) Autoconf web page, `http://www.gnu.org/software/autoconf/autoconf.html'. (2) Autoconf Gnats database, `http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=autoconf'. (3) CVSweb interface to the Autoconf development tree, `http://subversions.gnu.org/cgi-bin/cvsweb/autoconf/'. (4) Autoconf Macro Archive, `http://www.gnu.org/software/ac-archive/'. The GNU build system ******************** Autoconf solves an important problem--reliable discovery of system-specific build and runtime information--but this is only one piece of the puzzle for the development of portable software. To this end, the GNU project has developed a suite of integrated utilities to finish the job Autoconf started: the GNU build system, whose most important components are Autoconf, Automake, and Libtool. In this chapter, we introduce you to those tools, point you to sources of more information, and try to convince you to use the entire GNU build system for your software. Automake ======== The ubiquity of `make' means that a `Makefile' is almost the only viable way to distribute automatic build rules for software, but one quickly runs into `make''s numerous limitations. Its lack of support for automatic dependency tracking, recursive builds in subdirectories, reliable timestamps (e.g. for network filesystems), and so on, mean that developers must painfully (and often incorrectly) reinvent the wheel for each project. Portability is non-trivial, thanks to the quirks of `make' on many systems. On top of all this is the manual labor required to implement the many standard targets that users have come to expect (`make install', `make distclean', `make uninstall', etc.). Since you are, of course, using Autoconf, you also have to insert repetitive code in your `Makefile.in' to recognize `@CC@', `@CFLAGS@', and other substitutions provided by `configure'. Into this mess steps "Automake". Automake allows you to specify your build needs in a `Makefile.am' file with a vastly simpler and more powerful syntax than that of a plain `Makefile', and then generates a portable `Makefile.in' for use with Autoconf. For example, the `Makefile.am' to build and install a simple "Hello world" program might look like: bin_PROGRAMS = hello hello_SOURCES = hello.c The resulting `Makefile.in' (~400 lines) automatically supports all the standard targets, the substitutions provided by Autoconf, automatic dependency tracking, `VPATH' building, and so on. `make' will build the `hello' program, and `make install' will install it in `/usr/local/bin' (or whatever prefix was given to `configure', if not `/usr/local'). Automake may require that additional tools be present on the *developer's* machine. For example, the `Makefile.in' that the developer works with may not be portable (e.g. it might use special features of your compiler to automatically generate dependency information). Running `make dist', however, produces a `hello-1.0.tar.gz' package (or whatever the program/version is) with a `Makefile.in' that will work on any system. The benefits of Automake increase for larger packages (especially ones with subdirectories), but even for small programs the added convenience and portability can be substantial. And that's not all... Libtool ======= Very often, one wants to build not only programs, but libraries, so that other programs can benefit from the fruits of your labor. 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 independently of the linked programs. Producing shared libraries portably, however, is the stuff of nightmares--each system has its own incompatible tools, compiler flags, and magic incantations. Fortunately, GNU provides a solution: "Libtool". Libtool handles all the requirements of building shared libraries for you, and at this time seems to be the *only* way to do so with any portability. It also handles many other headaches, such as: the interaction of `Makefile' rules with the variable suffixes of shared libraries, linking reliably to shared libraries before they are installed by the superuser, and supplying a consistent versioning system (so that different versions of a library can be installed or upgraded without breaking binary compatibility). Although Libtool, like Autoconf, can be used on its own, it is most simply utilized in conjunction with Automake--there, Libtool is used automatically whenever shared libraries are needed, and you need not know its syntax. Pointers ======== Developers who are used to the simplicity of `make' for small projects on a single system might be daunted at the prospect of learning to use Automake and Autoconf. As your software is distributed to more and more users, however, you will otherwise quickly find yourself putting lots of effort into reinventing the services that the GNU build tools provide, and making the same mistakes that they once made and overcame. (Besides, since you're already learning Autoconf, Automake will be a piece of cake.) There are a number of places that you can go to for more information on the GNU build tools. - Web The home pages for Autoconf(1), Automake(2), and Libtool(3). - Automake Manual *Note Automake: (automake)Top, for more information on Automake. - Books The book `GNU Autoconf, Automake and Libtool'(4) describes the complete GNU build environment. You can also find the entire book on-line at "The Goat Book" home page(5). - Tutorials and Examples The Autoconf Developer Page(6) maintains links to a number of Autoconf/Automake tutorials online, and also links to the Autoconf Macro Archive(7). ---------- Footnotes ---------- (1) Autoconf, `http://www.gnu.org/software/autoconf/'. (2) Automake, `http://www.gnu.org/software/automake/'. (3) Libtool, `http://www.gnu.org/software/libtool/'. (4) `GNU Autoconf, Automake and Libtool', by G. V. Vaughan, B. Elliston, T. Tromey, and I. L. Taylor. New Riders, 2000, ISBN 1578701902. (5) "The Goat Book" home page, `http://sources.redhat.com/autobook/'. (6) Autoconf Developer Page, `http://sources.redhat.com/autoconf/'. (7) Autoconf Macro Archive, `http://www.gnu.org/software/ac-archive/'. 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, one in each subdirectory of the package (*note Makefile Substitutions::.); - optionally, a C header file, the name of which is configurable, containing `#define' directives (*note Configuration Headers::.); - a shell script called `config.status' that, when run, will recreate the files listed above (*note 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 (*note 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 ---' 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 *Note Existing Tests::, for their descriptions. For most other features, you can use Autoconf template macros to produce custom checks; see *Note Writing Tests::, for information about them. For especially tricky or specialized features, `configure.ac' might need to contain some hand-crafted shell commands; see *Note Portable Shell::. The `autoscan' program can give you a good start in writing `configure.ac' (*note autoscan Invocation::., 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. 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, 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 --------------------- 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`a, 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. 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 (*note Output::.). 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 (*note 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' 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 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' (*note Configuration Headers::.). You might also have to change or add some `#if' directives to your program in order to make it work with Autoconf (*note ifnames Invocation::., 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' is only installed if you already have Perl installed. `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. -autoconf-dir=DIR -A DIR Override the location where the installed Autoconf data files are looked for. You can also set the `AC_MACRODIR' environment variable to a directory; this option overrides the environment variable. This option is rarely needed and dangerous; it is only used when one plays with different versions of Autoconf simultaneously. 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' (*note autoscan Invocation::.). `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. 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 (*note 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. -autoconf-dir=DIR -A DIR Override the location where the installed Autoconf data files are looked for. You can also set the `AC_MACRODIR' environment variable to a directory; this option overrides the environment variable. This option is rarely needed and dangerous; it is only used when one plays with different versions of Autoconf simultaneously. -localdir=DIR -l DIR Look for the package file `aclocal.m4' in directory DIR instead of in the current directory. -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). *Note 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. autoconf -W CATEGORY will actually behave as if you had run: autoconf --warnings=syntax,$WARNINGS,CATEGORY