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.
Created Wed Sep 1 16:41:59 2004 on bee with info_to_html version 0.9.6.