Re: AC_COMPUTE_INT's arguments

[Stepan Kasal]

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