To avoid checking for the same features repeatedly in various
configure scripts (or repeated runs of one script),
configure saves the results of many of its checks in a cache
file. If, when a
configure script runs, it finds a cache file,
it reads from it the results from previous runs and avoids rerunning
those checks. As a result,
configure can run much faster than if
it had to perform all of the checks every time.
configurewas not given the `--quiet' or `--silent' option, print a message saying that the result was cached; otherwise, run the shell commands commands-to-set-it. Those commands should have no side effects except for setting the variable cache-id. In particular, they should not call
AC_DEFINE; the code that follows the call to
AC_CACHE_VALshould do that, based on the cached value. Also, they should not print any messages, for example with
AC_MSG_CHECKING; do that before calling
AC_CACHE_VAL, so the messages are printed regardless of whether the results of the check are retrieved from the cache or determined by running the shell commands. If the shell commands are run to determine the value, the value will be saved in the cache file just before
configurecreates its output files. See section Cache Variable Names, for how to choose the name of the cache-id variable.
AC_CACHE_VALthat takes care of printing the messages. This macro provides a convenient shorthand for the most common way to use these macros. It calls
AC_MSG_CHECKINGfor message, then
AC_CACHE_VALwith the cache-id and commands arguments, and
AC_OUTPUT, but it can be quite useful to call
AC_CACHE_SAVEat key points in configure.in. Doing so checkpoints the cache in case of an early configure script abort.
Go to the first, previous, next, last section, table of contents.