3.2 Files generated by configure

back: configuring
forward: the most useful makefile targets
fastback: the most useful makefile targets
up: invoking configure
fastforward: introducing makefiles
top: autoconf, automake, and libtool
contents: table of contents
index: index
about: about this document

After you have invoked `configure' , you will discover a number of generated files in your build tree. The build directory structure created by `configure' and the number of files will vary from package to package. Each of the generated files are described below and their relationships are shown in C. Generated File Dependencies:

`configure' can cache the results of system tests that have been performed to speed up subsequent tests. This file contains the cache data and is a plain text file that can be hand-modified or removed if desired.
As `configure' runs, it outputs a message describing each test it performs and the result of each test. There is substantially more output produced by the shell and utilities that `configure' invokes, but it is hidden from the user to keep the output understandable. The output is instead redirected to `config.log' . This file is the first place to look when `configure' goes hay-wire or a test produces a nonsense result. A common scenario is that `configure' , when run on a Solaris system, will tell you that it was unable to find a working C compiler. An examination of `config.log' will show that Solaris' default `/usr/ucb/cc' is a program that informs the user that the optional C compiler is not installed.
`configure' generates a shell script called `config.status' that may be used to recreate the current configuration. That is, all generated files will be regenerated. This script can also be used to re-run `configure' if the `--recheck' option is given.
Many packages that use `configure' are written in C or C++. Some of the tests that `configure' runs involve examining variability in the C and C++ programming languages and implementations thereof. So that source code can programmatically deal with these differences, #define preprocessor directives can be optionally placed in a config header , usually called `config.h' , as `configure' runs. Source files may then include the `config.h' file and act accordingly :
 #if HAVE_CONFIG_H #  include <config.h> #endif /* HAVE_CONFIG_H */ #if HAVE_UNISTD_H #  include <unistd.h> #endif /* HAVE_UNISTD_H */ 

We recommend always using a config header.

One of the common functions of `configure' is to generate `Makefile' s and other files. As it has been stressed, a `Makefile' is just a file often generated by `configure' from a corresponding input file (usually called `Makefile.in' ). The following section will describe how you can use make to process this `Makefile' . There are other cases where generating files in this way can be helpful. For instance, a Java developer might wish to make use of a `defs.java' file generated from `defs.java.in' .

This document was generated by Gary V. Vaughan on May, 24 2001 using texi2html

GNU Autoconf, Automake and Libtool
GNU Autoconf, Automake, and Libtool
ISBN: 1578701902
EAN: 2147483647
Year: 2002
Pages: 290

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net