Re: gl_CACHE_VAL_SILENT won't work correctly with upcoming autoconf 2.70

[Zack Weinberg <zackw@panix.com>]

On Fri, Mar 13, 2020 at 5:54 PM Bruno Haible <bruno@clisp.org> wrote:
>
> [CCing autoconf@gnu.org]
>
> Hi Zack,
>
> > Abstractly, the best thing to do about this would be to remove the
> > macro and change all of its uses to be AC_CACHE_CHECK, with proper
> > messaging, instead.
>
> The point is that we don't want messaging for some tests. Most people
> find the 'configure' output already long enough.

 I disagree with this on principle.  If you're doing any test that's
complicated enough to be worth caching, then you should use
AC_CACHE_CHECK and provide messaging for it.  Yeah, most of the time
that text is just going to scroll by unread, but when something goes
wrong, the poor schmuck who has to debug it wants to know that it was
the test for `ceil` (for instance) that hung the build, not the
unrelated thing that happens to have been tested right before that.

> The underlying problem in Autoconf is the following: There is a macro
> AC_CACHE_CHECK that does messaging, and a macro AC_CACHE_VAL whose
> main purpose is to make a cache lookup, not messaging, but it
> nevertheless outputs '(cached)' strings occasionally.

So based on the above my attitude is that AC_CACHE_VAL (and
AC_MSG_CHECKING and AC_MSG_RESULT) exist only for backward
compatibility's sake and what you're supposed to be using is
AC_CACHE_CHECK, and I'm not inclined to spend any of my own hacking
time on "a macro that is like AC_CACHE_VAL but produces no spurious
output".

On the other hand, if you write a patch and Paul or Eric likes it, I
won't stand in its way, either.

zw