Re: AC_PROG_CC_* shouldn't append multiple options

[Andrew W. Nosenko]

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.

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.

>
> cu
> Adrian
>
> [1] http://gcc.gnu.org/gcc-4.7/c99status.html
>

-- 
Andrew W. Nosenko <address@hidden>