Writing `configure.in'

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

The order in which `configure.in' calls the Autoconf macros is not important, with a few exceptions. Every `configure.in' must contain a call to AC_INIT before the checks, and a call to AC_OUTPUT at the end (see section Creating Output 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 creating configure 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 could depend on things earlier in it. For example, library functions could be affected by typedefs and libraries.

AC_INIT(file)
checks for programs
checks for libraries
checks for header files
checks for typedefs
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services
AC_OUTPUT([file...])

It is best to put each macro call on its own line in `configure.in'. 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.

When calling macros that take arguments, there must not be any blank space between the macro name and the open parenthesis. Arguments can be more than one line long if they are enclosed within the m4 quote characters `[' and `]'. If you have a long line such as a list of file names, you can generally use a backslash at the end of a line to continue it logically on the next line (this is implemented by the shell, not by anything special that Autoconf does).

Some macros handle two cases: what to do if the given condition is met, and what to do if the condition is not met. In some places you might want to do something if a condition is true but do nothing if it's false, or vice versa. To omit the true case, pass an empty value for the action-if-found argument to the macro. To omit the false case, omit the action-if-not-found argument to the macro, including the comma before it.

You can include comments in `configure.in' files by starting them with the m4 builtin macro dnl, which discards text up through the next newline. These comments do not appear in the generated configure scripts. For example, it is helpful to begin `configure.in' files with a line like this:

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

Go to the first, previous, next, last section, table of contents.