[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_PROG_CC_* shouldn't append multiple options
From: |
Adrian Bunk |
Subject: |
Re: AC_PROG_CC_* shouldn't append multiple options |
Date: |
Fri, 21 Sep 2012 16:21:38 +0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
- AC_PROG_CC_* shouldn't append multiple options, Adrian Bunk, 2012/09/20
- Re: AC_PROG_CC_* shouldn't append multiple options, Paul Eggert, 2012/09/20
- Re: AC_PROG_CC_* shouldn't append multiple options, Adrian Bunk, 2012/09/20
- Re: AC_PROG_CC_* shouldn't append multiple options, Paul Eggert, 2012/09/21
- Re: AC_PROG_CC_* shouldn't append multiple options, Andrew W. Nosenko, 2012/09/21
- Re: AC_PROG_CC_* shouldn't append multiple options, Adrian Bunk, 2012/09/21
- Re: AC_PROG_CC_* shouldn't append multiple options, Andrew W. Nosenko, 2012/09/21
- Re: AC_PROG_CC_* shouldn't append multiple options,
Adrian Bunk <=
- Re: AC_PROG_CC_* shouldn't append multiple options, Andrew W. Nosenko, 2012/09/21
- Re: AC_PROG_CC_* shouldn't append multiple options, Adrian Bunk, 2012/09/23
- Re: AC_PROG_CC_* shouldn't append multiple options, Andrew W. Nosenko, 2012/09/23
- Re: AC_PROG_CC_* shouldn't append multiple options, Adrian Bunk, 2012/09/21
- Re: AC_PROG_CC_* shouldn't append multiple options, Adrian Bunk, 2012/09/21