GNU Info

(autoconf.info)Cache Files

---

Prev: Cache Variable Names Up: Caching Results

---

Enter node , (file) or (file)node

Cache Files
-----------

   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.  Note: 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 (Note: 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 (Note:
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)