GNU Info

(autoconf.info)Writing configure.in

---

Next: Invoking autoscan Prev: Making configure Scripts Up: Making configure Scripts

---

Enter node , (file) or (file)node

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 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.in' might need to contain some
hand-crafted shell commands.  The `autoscan' program can give you a
good start in writing `configure.in' (Note: Invoking autoscan, 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 (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 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.