Re: Using AC_CACHE_CHECK with AC_ARG_ENABLE/AC_ARG_WITH?

[Ralf Wildenhues]

Hi J.T.,

I've adjusted the subject to be a bit better searchable.

* J.T. Conklin wrote on Wed, Mar 08, 2006 at 11:34:43PM CET:
> The autoconf manual has the following example for AS_HELP_STRING:
> 
>     AC_DEFUN([TEST_MACRO],
>     [AC_ARG_WITH([foo],
>                  AS_HELP_STRING([--with-foo],
>                                 [use foo (default is NO)]),
>                  [ac_cv_use_foo=$withval], [ac_cv_use_foo=no])
>     AC_CACHE_CHECK([whether to use foo],
>                    [ac_cv_use_foo], [ac_cv_use_foo=no])])
> 
> I've seen this idiom of using AC_CACHE_CHECK after AC_ARG_ENABLE and
> ACE_ARG_WITH elsewhere, but I do not really understand what benefits
> caching brings.  For example, in the above ac_cv_use_foo is going to
> be set one way or the other before the call to AC_CACHE_CHECK, so the
> COMMANDS-TO-SET-IT will never be invoked.  

I agree.  I think the example is bogus.  Or maybe it was useful at one
time in the past because it caused the `--with-foo' setting to be
preserved, even when the user did a manual
  ./configure

without it.  But that is not true for Autoconf-2.59, and I have no idea
whether it ever was true.  Note that automatic rerunning by
  config.status --recheck

is not affected by this at all: it invokes configure with the right
optinos.

> If the point is to print a message, why not use something like:
> 
>     AC_MSG_CHECKING([whether to use foo])
>     AC_MSG_RESULT($ac_cv_use_foo)
> 
> ?

Well, I don't like the idea of using cache variables without announcing
them to Autoconf as a CACHE-ID.  But using a cache variable at all here
seems weird to me (unless there is a bug in Autoconf, as hinted above).

Cheers,
Ralf