Feedback about 2.60a:
In contrast to _AC_COMPUTE_INT, AC_COMPUTE_INT wants a message argument,
and uses it for AC_CACHE_CHECK.
The macro would be more useful without this message argument, i.e.
with AC_CACHE_VAL instead of AC_CACHE_CHECK.
Reason 1: Example: In this code (taken from ptrdiff_max.m4)
_AC_COMPUTE_INT([sizeof (ptrdiff_t) <= sizeof (int)], fits_in_int)
what could I reasonably give as message? I could try this:
checking whether ptrdiff_t fits into an int... 1
but it looks awful and creates confusion.
In other cases, only an AC_COMPUTE_INT combined with some other statements
is a unit that can reasonably be shown to the user.
Reason 2: The lesson learned from Lisp. Lisp at some time introduced a
primitive called 'prog', that was useful for binding variables, establishing
a scope for 'go' and a block for 'return'. It turned out that the primitive
for binding variables, now called 'let', was much more useful than the
combined 'prog'.
After all, the user wants to output a message can do so himself, with
AC_MSG_CHECKING and AC_MSG_RESULT.
Bruno
