@dircategory GNU admin @direntry * configure: (configure). The GNU configure and build system
Copyright (C) 1998 Cygnus Solutions
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.
This document describes the GNU configure and build systems. It describes how autoconf, automake, libtool, and make fit together. It also includes a discussion of the older Cygnus configure system.
This document does not describe in detail how to use each of the tools; see the respective manuals for that. Instead, it describes which files the developer must write, which files are machine generated and how they are generated, and where certain common problems should be addressed.
This document draws on several sources, including the autoconf manual by David MacKenzie, the automake manual by David MacKenzie and Tom Tromey, the libtool manual by Gordon Matzigkeit, and the Cygnus configure manual by K. Richard Pixley.
The GNU configure and build system has two main goals.
The first is to simplify the development of portable programs. The system permits the developer to concentrate on writing the program, simplifying many details of portability across Unix and even Windows systems, and permitting the developer to describe how to build the program using simple rules rather than complex Makefiles.
The second is to simplify the building of programs distributed as source code. All programs are built using a simple, standardized, two step process. The program builder need not install any special tools in order to build the program.
The GNU configure and build system is comprised of several different tools. Program developers must build and install all of these tools.
People who just want to build programs from distributed sources normally do not need any special tools beyond a Unix shell, a make program, and a C compiler.
This is a very brief and probably inaccurate history.
As the number of Unix variants increased during the 1980s, it became
harder to write programs which could run on all variants. While it was
often possible to use #ifdef to identify particular systems,
developers frequently did not have access to every system, and the
characteristics of some systems changed from version to version.
By 1992, at least three different approaches had been developed:
The Metaconfig program is still used for Perl and a few other programs. It is part of the Dist package. I do not know if it is being developed.
In 1994, David MacKenzie and others modified autoconf to incorporate all the features of Cygnus configure. Since then, there has been a slow but steady conversion of GNU programs from Cygnus configure to autoconf. gcc has been converted, eliminating the gcc configure script.
GNU autoconf was regularly maintained until late 1996. As of this writing in June, 1998, it has no public maintainer.
Most programs are built using the make program, which requires the developer to write Makefiles describing how to build the programs. Since most programs are built in pretty much the same way, this led to a lot of duplication.
The X Window system is built using the imake tool, which uses a database of rules to eliminate the duplication. However, building a tool which was developed using imake requires that the builder have imake installed, violating one of the goals of the GNU system.
The new BSD make provides a standard library of Makefile fragments, which permits developers to write very simple Makefiles. However, this requires that the builder install the new BSD make program.
In 1994, David MacKenzie wrote the first version of automake, which permitted writing a simple build description which was converted into a Makefile which could be used by the standard make program. In 1995, Tom Tromey completely rewrote automake in Perl, and he continues to enhance it.
Various free packages built libraries, and by around 1995 several included support to build shared libraries on various platforms. However, there was no consistent approach. In early 1996, Gordon Matzigkeit began working on libtool, which provided a standardized approach to building shared libraries. This was integrated into automake from the start.
The development of automake and libtool was driven by the GNITS project, a group of GNU maintainers who designed standardized tools to help meet the GNU coding standards.
Most readers of this document should already know how to build a tool by running `configure' and `make'. This section may serve as a quick introduction or reminder.
Building a tool is normally as simple as running `configure' followed by `make'. You should normally run `configure' from an empty directory, using some path to refer to the `configure' script in the source directory. The directory in which you run `configure' is called the object directory.
In order to use a object directory which is different from the source directory, you must be using the GNU version of `make', which has the required `VPATH' support. Despite this restriction, using a different object directory is highly recommended:
If you don't have GNU `make', you will have to run `configure' in the source directory. All GNU packages should support this; in particular, GNU packages should not assume the presence of GNU `make'.
After running `configure', you can build the tools by running `make'.
To install the tools, run `make install'. Installing the tools will copy the programs and any required support files to the installation directory. The location of the installation directory is controlled by `configure' options, as described below.
In the Cygnus tree at present, the info files are built and installed as a separate step. To build them, run `make info'. To install them, run `make install-info'.
All `configure' scripts support a wide variety of options. The most interesting ones are `--with' and `--enable' options which are generally specific to particular tools. You can usually use the `--help' option to get a list of interesting options for a particular configure script.
The only generic options you are likely to use are the `--prefix' and `--exec-prefix' options. These options are used to specify the installation directory.
The directory named by the `--prefix' option will hold machine independent files such as info files.
The directory named by the `--exec-prefix' option, which is normally a subdirectory of the `--prefix' directory, will hold machine dependent files such as executables.
The default for `--prefix' is `/usr/local'. The default for `--exec-prefix' is the value used for `--prefix'.
The convention used in Cygnus releases is to use a `--prefix' option of `/usr/cygnus/release', where release is the name of the release, and to use a `--exec-prefix' option of `/usr/cygnus/release/H-host', where host is the configuration name of the host system (see section Configuration Names).
Do not use either the source or the object directory as the installation directory. That will just lead to confusion.
Go to the first, previous, next, last section, table of contents.