| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 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’.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated by Ben Elliston on July 10, 2015 using texi2html 1.82.