Hello,
On Sat, Sep 02, 2006 at 12:09:49PM +0200, Ralf Wildenhues wrote:
> * Bruno Haible wrote on Fri, Sep 01, 2006 at 02:05:26PM CEST:
> >
> > _AC_COMPUTE_INT([sizeof (ptrdiff_t) <= sizeof (int)], fits_in_int)
>
> This example would benefit from a public AC_LANG_BOOL_COMPILE_TRY macro:
indeed, that was my first reaction, too: you are abusing the macro, so no
wonder there are surprises. A new macro should be designed for this.
What about introducing
AC_LANG_BOOL_COMPILE_IFELSE(prologue, bool-expr, if-true, if-false)
as a public macro? (We would document that it is implemented only for
the three C languages.)
Then AC_COMPUTE_INT would be than built on top of this. Perhaps it
should be renamed to AC_LANG_COMPUTE_INT, even though it would be
documented that is is implemented only for one language: C.
> But that public version would have to include the cast to long int,
> for the HP compiler, which would be at least a bit ugly.
Ralf, could you please give me a reference to the problem?
(My naive opinion is that we should not give up the clean API for
a problem with a particular vedor.)
> * Paul Eggert wrote on Sat, Sep 02, 2006 at 07:40:31AM CEST:
> > commonly-needed thing. Let's call it AC_CACHE_CHECK_INT since it's a
> > combination of AC_CACHE_CHECK and AC_COMPUTE_INT; that's a better
I think this step moved things the right direction.
But I wonder whether it is worth it to have a special name for a
trivial and natural combination of two macros.
Perhaps AC_CACHE_CHECK_INT could be dropped?
Have a nice day,
Stepan