[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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').
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).
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').
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.
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.
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] | [ ? ] |