[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spurious "(cached)" output from AC_CACHE_VAL

From: Bruno Haible
Subject: Re: spurious "(cached)" output from AC_CACHE_VAL
Date: Fri, 27 Feb 2009 23:36:31 +0100
User-agent: KMail/1.9.9

[Adding bug-autoconf list to CC.]

For the context: in gnulib, I today added a macro:

# gl_CACHE_VAL_SILENT(cache-id, command-to-set-it)
# is like AC_CACHE_VAL(cache-id, command-to-set-it), except that it does not
# output a spurious "(cached)" mark in the midst of other configure output.
# This macro should be used instead of AC_CACHE_VAL when it is not surrounded

Eric Blake wrote in 
> But your patch has merit in that it makes a nice macro name that explains 
> what 
> you are intending.

It would even be better if this macro was not needed. Couldn't AC_CACHE_VAL be
changed to output "(cached)" when run between AC_MSG_CHECKING and
AC_MSG_RESULT, and be silent otherwise?

The implementation of this change would be that AC_CACHE_VAL invokes a
macro made for this purpose, say, _AC_ECHO_CACHED. AC_MSG_CHECKING would
pushdef _AC_ECHO_CACHED to a definition that expands to nothing or a ':'
command, and AC_MSG_RESULT would popdef it.

> _cv_
>     Indicates that this shell variable is a cache value. This string must be 
> present in the variable name, including the leading underscore. 

Yes, this is well known.

> If you'd like, I'll even add another sentence to the autoconf manual that 
> makes 
> it clear that all such variables with this naming scheme, regardless of how 
> they are used, are cached.

I would *not* document this. If you document it, it may cause additional effort
if you or Ralf want to change the implementation of caching, sometime in the
future. There is no functional benefit for the user either: users can use


reply via email to

[Prev in Thread] Current Thread [Next in Thread]