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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf