Re: bad config.h on Solaris 8

[Akim Demaille]

| Recap of problem: configure script doesn't generate config.h on the
| basis of results from tests.  Removing config.cache and rerunning
| configure yeilds a correct config.h.
| 
| > What version of Autoconf?
| 
| 2.13 and 2.50.

Hm...  Does autoconf 2.50 complain when you run it?  A common mistake
consists is explained below.  Please, check your configure.in and aclocal.m4.

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" (*note
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 will
     be saved in the cache file just before `configure' creates its
     output files.  *Note 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 very 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_DEFUN([AC_SHELL_TRUE],
     [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
                     [ac_cv_shell_true_works=no
                      true && 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.])
                      fi])
     ])

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_DEFUN([AC_SHELL_TRUE],
     [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
                     [ac_cv_shell_true_works=no
                      true && 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.])
      fi
     ])

   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.