configure.info: Write configure.in

Go forward to Write Makefile.am
Go up to Getting Started
Go to the top op configure

Write configure.in

   You must first write the file `configure.in'.  This is an autoconf
input file, and the autoconf manual describes in detail what this file
should look like.
   You will write tests in your `configure.in' file to check for
conditions that may change from one system to another, such as the
presence of particular header files or functions.
   For example, not all systems support the `gettimeofday' function.
If you want to use the `gettimeofday' function when it is available,
and to use some other function when it is not, you would check for this
by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'.
   When the configure script is run at build time, this will arrange to
define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the
`gettimeofday' function is available, and to not define the macro at
all if the function is not available.  Your code can then use `#ifdef'
to test whether it is safe to call `gettimeofday'.
   If you have an existing body of code, the `autoscan' program may
help identify potential portability problems, and hence configure tests
that you will want to use.  *Note Invoking autoscan: (autoconf)Invoking
autoscan.
   Another handy tool for an existing body of code is `ifnames'.  This
will show you all the preprocessor conditionals that the code already
uses.  *Note Invoking ifnames: (autoconf)Invoking ifnames.
   Besides the portability tests which are specific to your particular
package, every `configure.in' file should contain the following macros.
`AC_INIT'
     This macro takes a single argument, which is the name of a file in
     your package.  For example, `AC_INIT(foo.c)'.
`AC_PREREQ(VERSION)'
     This macro is optional.  It may be used to indicate the version of
     `autoconf' that you are using.  This will prevent users from
     running an earlier version of `autoconf' and perhaps getting an
     invalid `configure' script.  For example, `AC_PREREQ(2.12)'.
`AM_INIT_AUTOMAKE'
     This macro takes two arguments: the name of the package, and a
     version number.  For example, `AM_INIT_AUTOMAKE(foo, 1.0)'.  (This
     macro is not needed if you are not using automake).
`AM_CONFIG_HEADER'
     This macro names the header file which will hold the preprocessor
     macro definitions at run time.  Normally this should be
     `config.h'.  Your sources would then use `#include "config.h"' to
     include it.
     This macro may optionally name the input file for that header
     file; by default, this is `config.h.in', but that file name works
     poorly on DOS filesystems.  Therefore, it is often better to name
     it explicitly as `config.in'.
     This is what you should normally put in `configure.in':
          AM_CONFIG_HEADER(config.h:config.in)
     (If you are not using automake, use `AC_CONFIG_HEADER' rather than
     `AM_CONFIG_HEADER').
`AM_MAINTAINER_MODE'
     This macro always appears in Cygnus configure scripts.  Other
     programs may or may not use it.
     If this macro is used, the `--enable-maintainer-mode' option is
     required to enable automatic rebuilding of generated files used by
     the configure system.  This of course requires that developers be
     aware of, and use, that option.
     If this macro is not used, then the generated files will always be
     rebuilt automatically.  This will cause problems if the wrong
     versions of autoconf, automake, or others are in the builder's
     `PATH'.
     (If you are not using automake, you do not need to use this macro).
`AC_EXEEXT'
     Either this macro or `AM_EXEEXT' always appears in Cygnus configure
     files.  Other programs may or may not use one of them.
     This macro looks for the executable suffix used on the host
     system.  On Unix systems, this is the empty string.  On Windows
     systems, this is `.exe'.  This macro directs automake to use the
     executable suffix as appropriate when creating programs.  This
     macro does not take any arguments.
     The `AC_EXEEXT' form is new, and is part of a Cygnus patch to
     autoconf to support compiling with Visual C++.  Older programs use
     `AM_EXEEXT' instead.
     (Programs which do not use automake use neither `AC_EXEEXT' nor
     `AM_EXEEXT').
`AC_PROG_CC'
     If you are writing C code, you will normally want to use this
     macro.  It locates the C compiler to use.  It does not take any
     arguments.
     However, if this `configure.in' file is for a library which is to
     be compiled by a cross compiler which may not fully work, then you
     will not want to use `AC_PROG_CC'.  Instead, you will want to use a
     variant which does not call the macro `AC_PROG_CC_WORKS'.  Examples
     can be found in various `configure.in' files for libraries that are
     compiled with cross compilers, such as libiberty or libgloss.
     This is essentially a bug in autoconf, and there will probably be
     a better workaround at some point.
`AC_PROG_CXX'
     If you are writing C++ code, you will want to use this macro.  It
     locates the C++ compiler to use.  It does not take any arguments.
     The same cross compiler comments apply as for `AC_PROG_CC'.
`AM_PROG_LIBTOOL'
     If you want to build libraries, and you want to permit them to be
     shared, or you want to link against libraries which were built
     using libtool, then you will need this macro.  This macro is
     required in order to use libtool.
     By default, this will cause all libraries to be built as shared
     libraries.  To prevent this-to change the default-use
     `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'.  The configure
     options `--enable-shared' and `--disable-shared' may be used to
     override the default at build time.
`AC_DEFINE(_GNU_SOURCE)'
     GNU packages should normally include this line before any other
     feature tests.  This defines the macro `_GNU_SOURCE' when
     compiling, which directs the libc header files to provide the
     standard GNU system interfaces including all GNU extensions.  If
     this macro is not defined, certain GNU extensions may not be
     available.
`AC_OUTPUT'
     This macro takes a list of file names which the configure process
     should produce.  This is normally a list of one or more `Makefile'
     files in different directories.  If your package lives entirely in
     a single directory, you would use simply `AC_OUTPUT(Makefile)'.
     If you also have, for example, a `lib' subdirectory, you would use
     `AC_OUTPUT(Makefile lib/Makefile)'.
   If you want to use locally defined macros in your `configure.in'
file, then you will need to write a `acinclude.m4' file which defines
them (if not using automake, this file is called `aclocal.m4').
Alternatively, you can put separate macros in an `m4' subdirectory, and
put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the
`aclocal' program will be able to find them.
   The different macro prefixes indicate which tool defines the macro.
Macros which start with `AC_' are part of autoconf.  Macros which start
with `AM_' are provided by automake or libtool.