bug-autoconf
[Top][All Lists]
Advanced

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

Re: AC_PROG_CC_* shouldn't append multiple options


From: Andrew W. Nosenko
Subject: Re: AC_PROG_CC_* shouldn't append multiple options
Date: Fri, 21 Sep 2012 17:41:36 +0300

On Fri, Sep 21, 2012 at 4:21 PM, Adrian Bunk <address@hidden> wrote:
> On Fri, Sep 21, 2012 at 03:59:14PM +0300, Andrew W. Nosenko wrote:
>> On Fri, Sep 21, 2012 at 12:13 PM, Adrian Bunk <address@hidden> wrote:
>> > On Fri, Sep 21, 2012 at 11:18:03AM +0300, Andrew W. Nosenko wrote:
>> >> On Fri, Sep 21, 2012 at 8:20 AM, Paul Eggert <address@hidden> wrote:
>> >> > Yup, macros that invoke AC_PROG_CC_C89 and AC_PROG_CC_C99
>> >> > are trouble.  They're trouble now, and they'll continue to
>> >> > be trouble.  It's not clear how to fix this, other than
>> >> > to advise people to avoid those macros, which the patch
>> >> > does in the manual.
>> >> >
>> >>
>> >> OK.  Assuming that AC_PROG_CC_C99 deprecated and then removed, how I
>> >> supposed to express "give me c99 or higher compiler or raise error if
>> >> there only c89 or lower compiler found"?  In another words: How can I
>> >> set the _lower_ bound of C standard support, after that configure
>> >> should stop trying and just raises an error?
>> >
>> > The problem here are the exact semantics of "c99 or higher compiler".
>> >
>> > Take gcc as an example:
>> > - in it's default (non-strict) C89 mode it supports some C99
>> >   features like "long long int"
>> > - no version of gcc so far supports C99 completely [1]
>> >
>> > What exactly are your usecases where you need to know the mode of the
>> > compiler, and not whether some specific C99 features are supported?
>>
>> Semantics is the same as for AC_PROG_CC_STDC in respect to pre ANSI C
>> compilers.  AFAIK it scans down to c89 and stops rejecting the
>> K&R-only compilers.
>
> Wrong, AC_PROG_CC_STDC does not reject any compilers.
> Neither does AC_PROG_CC_C99.
>
> They set a variables where you can use to check whether autoconf
> succeeded to bring the compiler into the requested mode or not.
>
> If you assume in you configure.ac that AC_PROG_CC_C99 fails on pre-C99
> compilers that's a bug you have to fix.
>
> Note that K&R compilers are no longer an issue today, so no need to test
> for them.
>
>> Just fast forward in minds some years further.  c89 will be so ancient
>> that it will be simplier just to drop it completely than try to
>> workaround, same as today projects just prefer to ask user to upgrade
>> compiler than play the game with unprotoize.
>>
>> Or, you asked "after what what compiler (plus language support
>> library) should be considered as enough close to c99 for be counted as
>> c99"?
>> For me, the AC_PROG_CC_99 was good enough in that respect.
>
> You have ensured not to use any C99 features not tested by
> AC_PROG_CC_C99 in your code?
>

Are you indeed belive in compiler, which claims to be c99 and doesn't
support  _Bool and variadic macros?

-- 
Andrew W. Nosenko <address@hidden>



reply via email to

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