A cache file is a shell script that caches the results of configure tests run on one system so they can be shared between configure scripts and configure runs. It is not useful on other systems. If its contents are invalid for some reason, the user may delete or edit it.
By default, configure uses `./config.cache' as the cache file,
creating it if it does not exist already. configure accepts the
`--cache-file=file' option to use a different cache file;
that is what configure does when it calls configure
scripts in subdirectories, so they share the cache.
See section Configuring Other Packages in Subdirectories, for information on configuring subdirectories
with the AC_CONFIG_SUBDIRS macro.
Giving `--cache-file=/dev/null' disables caching, for debugging
configure. `config.status' only pays attention to the cache
file if it is given the `--recheck' option, which makes it rerun
configure. If you are anticipating a long debugging period, you
can also disable cache loading and saving for a configure script
by redefining the cache macros at the start of `configure.in':
define([AC_CACHE_LOAD], )dnl define([AC_CACHE_SAVE], )dnl AC_INIT(whatever) ... rest of configure.in ...
It is wrong to try to distribute cache files for particular system types. There is too much room for error in doing that, and too much administrative overhead in maintaining them. For any features that can't be guessed automatically, use the standard method of the canonical system type and linking files (see section Manual Configuration).
The cache file on a particular system will gradually accumulate whenever
someone runs a configure script; it will be initially
nonexistent. Running configure merges the new cache results with
the existing cache file. The site initialization script can specify a
site-wide cache file to use instead of the default, to make it work
transparently, as long as the same C compiler is used every time
(see section Setting Site Defaults).
If your configure script, or a macro called from configure.in, happens to abort the configure process, it may be useful to checkpoint the cache a few times at key points. Doing so will reduce the amount of time it takes to re-run the configure script with (hopefully) the error that caused the previous abort corrected.
... AC_INIT, etc. ... dnl checks for programs AC_PROG_CC AC_PROG_GCC_TRADITIONAL ... more program checks ... AC_CACHE_SAVE dnl checks for libraries AC_CHECK_LIB(nsl, gethostbyname) AC_CHECK_LIB(socket, connect) ... more lib checks ... AC_CACHE_SAVE dnl Might abort... AM_PATH_GTK(1.0.2, , exit 1) AM_PATH_GTKMM(0.9.5, , exit 1)
Go to the first, previous, next, last section, table of contents.