[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

23.4 Implementation specifics

This section provides some tips about how to actually go about writing your macros once you’ve decided what it is that you want to test and how to go about testing for it. It covers writing shell code for the test and optionally caching the results of those tests.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

23.4.1 Writing shell code

It is necessary to adopt a technique of writing portable Bourne shell code. Often, shell programming tricks you might have learned are actually extensions provided by your favorite shell and are non-portable. When in doubt, check documentation or try the construct on another system’s Bourne shell. For a thorough treatment of this topic, Writing Portable Bourne Shell.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

23.4.2 Using M4 correctly

Writing macros involves interacting with the M4 macro processor, which expands your macros when they are used in ‘configure.in’. It is crucial that your macros use M4 correctly–and in particular, that they quote strings correctly. M4 for a thorough treatment of this topic.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

23.4.3 Caching results

Autoconf provides a caching facility, whereby the results of a test may be stored in a cache file. The cache file is itself a Bourne shell script which is sourced by the ‘configure’ script to set any ‘cache variables’ to values that are present in the cache file.

The next time ‘configure’ is run, the cache will be consulted for a prior result. If there is a prior result, the value is re-used and the code that performs that test is skipped. This speeds up subsequent runs of ‘configure’ and configuration of deep trees, which can share a cache file in the top-level directory (see section How to run configure and make).

A custom macro is not required to do caching, though it is considered best practice. Sometimes it doesn’t make sense for a macro to do caching–tests for system aspects which may frequently change should not be cached. For example, a test for free disk space should not employ caching as it is a dynamic characteristic.

The ‘AC_CACHE_CHECK’ macro is a convenient wrapper for caching the results of tests. You simply provide a description of the test, the name of a cache variable to store the test result to, and the body of the test. If the test has not been run before, the cache will be primed with the result. If the result is already in the cache, then the cache variable will be set and the test will be skipped. Note that the name of the cache variable must contain ‘_cv_’ in order to be saved correctly.

Here is the code for an Autoconf macro that ties together many of the concepts introduced in this chapter:

 
# AC_PROG_CC_G
# ------------
AC_DEFUN(AC_PROG_CC_G,
[AC_CACHE_CHECK(whether ${CC-cc} accepts -g, ac_cv_prog_cc_g,
[echo 'void f(){}' > conftest.c
if test -z "${CC-cc} -g -c conftest.c 2>&1`"; then
  ac_cv_prog_cc_g=yes
else
  ac_cv_prog_cc_g=no
fi
rm -f conftest*
])]) # AC_PROG_CC_G


[ < ] [ > ]   [ << ] [ Up ] [ >> ]

This document was generated by Ben Elliston on July 10, 2015 using texi2html 1.82.