[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AC_COMPUTE_INT's arguments
From: |
Bruno Haible |
Subject: |
AC_COMPUTE_INT's arguments |
Date: |
Fri, 1 Sep 2006 14:05:26 +0200 |
User-agent: |
KMail/1.9.1 |
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
- AC_COMPUTE_INT's arguments,
Bruno Haible <=
- Re: AC_COMPUTE_INT's arguments, Paul Eggert, 2006/09/02
- Re: AC_COMPUTE_INT's arguments, Ralf Wildenhues, 2006/09/02
- Re: AC_COMPUTE_INT's arguments, Stepan Kasal, 2006/09/02
- Re: AC_COMPUTE_INT's arguments, Paul Eggert, 2006/09/02
- Re: AC_COMPUTE_INT's arguments, Ralf Wildenhues, 2006/09/03
- Re: AC_COMPUTE_INT's arguments, Stepan Kasal, 2006/09/04
- Re: AC_COMPUTE_INT's arguments, Ralf Wildenhues, 2006/09/04
- Re: AC_COMPUTE_INT's arguments, Stepan Kasal, 2006/09/06