Re: Improve AC_CACHE_VAL

[Bruno Haible]

Eric Blake wrote:
> Bruno, since you raised the original issue, what do you think of this
> counterproposal?

I agree now that a shell-based solution is better than something based on
pushdef/popdef. For instance, gnulib's lib-ld.m4 has a construct like this:

  if ...; then
    AC_MSG_CHECKING([for ld used by GCC])
  elif ...; then
    AC_MSG_CHECKING([for GNU ld])
  else
    AC_MSG_CHECKING([for non-GNU ld])
  fi
  AC_CACHE_VAL(...)
  if ...; then
    AC_MSG_RESULT([$LD])
  else
    AC_MSG_RESULT([no])
  fi

I don't agree that autoconf should provide macros AC_SILENT_PUSH/AC_SILENT_POP,
for the user to invoke. The problem with the "(cached)" output is a problem
made by autoconf; it should not be the task of the user to fix up artefacts
of autoconf's implementation. Additionally, who wants to write two macro
calls in order to get rid of a single word of only cosmetically relevant
output? If this is the proposed solution, then IMO the status quo is better.

The exec trick with the fd is reasonable. However, the AS_MESSAGE_FD is too
important to fiddle with. If it does not get reset, the entire output from
configure stops. In other words, the scope of what can go wrong is too large.

So what I would prefer is:
  - Set up an secondary message file descriptor, initially pointing to
    the same destination as AS_MESSAGE_FD. This way, no damage can happen to
    AS_MESSAGE_FD.
  - Create undocumented macros _AC_SECONDARY_SILENT_PUSH,
    AC_SECONDARY_SILENT_POP, that redirect the secondary message file
    descriptor, like shown by Paolo, but changed to work in the above
    situation with 'if's.
  - Invoke these macros from AC_MSG_CHECKING and AC_MSG_RESULT.
  - Use the secondary message file descriptor in AC_CACHE_VAL.

Bruno