bug-gnulib
[Top][All Lists]
Advanced

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

Re: spurious roundl output (was: computing long double NaN on Irix 6.5)


From: Eric Blake
Subject: Re: spurious roundl output (was: computing long double NaN on Irix 6.5)
Date: Fri, 27 Feb 2009 18:10:40 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Bruno Haible <bruno <at> clisp.org> writes:

> > A variable with _cv_ in the name is still cached, regardless of whether
> > you used AC_CACHE_VAL; all AC_CACHE_VAL does is wrap additional logic to
> > produce output, thus it should not be used in situations where you don't
> > want the side effect of output.
> 
> "AC_CACHE_VAL does is wrap additional logic to produce output" - that is
> something that may be valid in the current autoconf. But the documentation
> of AC_CACHE_VAL is clear about the fact that it is the AC_CACHE_VAL
> invocation that ensures the caching of the variable. The fact that - 
currently -
> a variable with _cv_ in its name is cached even without an AC_CACHE_VAL
> invocation is undocumented; you might even say that it's a bug. Therefore I
> find it unwise to rely on that.

I think it's well-documented that _cv_ forms cache variables, which are cached 
independently of whether you used AC_CACHE_VAL:

http://www.gnu.org/software/autoconf/manual/autoconf.html#Cache-Variable-Names

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

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'm applying this instead. It also relies on an undocumented detail (the
> as_echo_n variable), but it will be less hairy to fix if it breaks in
> future versions of autoconf.

But your patch has merit in that it makes a nice macro name that explains what 
you are intending.  I've also seen instances of (cached) (cached) appear when 
checking for gcj, so you may need to check the javacomp 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
> +# by an AC_MSG_CHECKING/AC_MSG_RESULT pair.
> +AC_DEFUN([gl_CACHE_VAL_SILENT],
> +[
> +  saved_as_echo_n="$as_echo_n"
> +  as_echo_n=':'
> +  AC_CACHE_VAL([$1], [$2])
> +  as_echo_n="$saved_as_echo_n"

Three instances of spurious shell quotes, but I also know you prefer that 
verbose style, so I won't ask you to change it.

-- 
Eric Blake







reply via email to

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