Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




7.4 Caching Results

To avoid checking for the same features repeatedly in various configure scripts (or in repeated runs of one script), configure can optionally save the results of many checks in a cache file (see Cache Files). If a configure script runs with caching enabled and finds a cache file, it reads the results of previous runs from the cache and avoids rerunning those checks. As a result, configure can then run much faster than if it had to perform all of the checks every time.

— Macro: AC_CACHE_VAL (cache-id, commands-to-set-it)

Ensure that the results of the check identified by cache-id are available. If the results of the check were in the cache file that was read, and 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. If the shell commands are run to determine the value, the value is saved in the cache file just before configure creates its output files. See Cache Variable Names, for how to choose the name of the cache-id variable.

The commands-to-set-it must have no side effects except for setting the variable cache-id, see below.

— Macro: AC_CACHE_CHECK (message, cache-id, commands-to-set-it)

A wrapper for 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.

The commands-to-set-it must have no side effects except for setting the variable cache-id, see below.

It is common to find buggy macros using AC_CACHE_VAL or AC_CACHE_CHECK, because people are tempted to call AC_DEFINE in the commands-to-set-it. Instead, the code that follows the call to AC_CACHE_VAL should call AC_DEFINE, by examining the value of the cache variable. For instance, the following macro is broken:

     [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
                      (true) 2>/dev/null && ac_cv_shell_true_works=yes
                      if test "$ac_cv_shell_true_works" = yes; then
                        AC_DEFINE([TRUE_WORKS], [1],
                                  [Define if `true(1)' works properly.])

This fails if the cache is enabled: the second time this macro is run, TRUE_WORKS will not be defined. The proper implementation is:

     [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
                      (true) 2>/dev/null && ac_cv_shell_true_works=yes])
      if test "$ac_cv_shell_true_works" = yes; then
        AC_DEFINE([TRUE_WORKS], [1],
                  [Define if `true(1)' works properly.])

Also, commands-to-set-it 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.

  Published under the terms of the GNU General Public License Design by Interspire