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.
configure
was 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_VAL
should 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 configure
creates its output files. See section Cache Variable Names, for how to choose the name of the cache-id variable.
AC_CACHE_VAL
that 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_CHECKING
for
message, then AC_CACHE_VAL
with the cache-id and
commands arguments, and AC_MSG_RESULT
with cache-id.
AC_INIT
.
AC_OUTPUT
, but it can be quite useful to call
AC_CACHE_SAVE
at 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.