bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_COMPUTE_INT's arguments


From: Ralf Wildenhues
Subject: Re: AC_COMPUTE_INT's arguments
Date: Sun, 3 Sep 2006 10:00:08 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello,

* Stepan Kasal wrote on Sat, Sep 02, 2006 at 02:41:48PM CEST:
> 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:
>
> 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.)

Probably a good idea.

> > 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?

See the comment in the implementation of AC_CHECK_SIZEOF.

> (My naive opinion is that we should not give up the clean API for
> a problem with a particular vedor.)

IMHO that's the wrong way around.  Autoconf is all about existing
limitations and bugs, and its API tries to capture or wrap what is
portably possible.  I wonder though whether casting an expression
of some integer type that is either true or false, to long int is
really a limitation (but maybe I remember the problem wrongly).

> 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?

* Paul Eggert wrote on Sat, Sep 02, 2006 at 11:23:53PM CEST:
> 
> It is a close call.  It does capture a common pattern, which is used
> twice within Autoconf itself and could be used in Gnulib (in the
> stdint module).  But if there's sentiment to drop it, now's the time.

FWIW, I don't have a strong opinion either way.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]