[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2.1 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. See the autoscan documentation.

Another handy tool for an existing body of code is `ifnames'. This will show you all the preprocessor conditionals that the code already uses. See the ifnames documentation.

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by system on December, 2 2004 using texi2html