autoconf
[Top][All Lists]
Advanced

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

Re: AC_PROG_CC_C99


From: Dan Manthey
Subject: Re: AC_PROG_CC_C99
Date: Tue, 28 Dec 2004 13:32:55 -0500

Hi.

I'm new to this list, so I may be fuddled.  Please flame me only for my own
benefit.

I'm using autoconf 2.59, so I copied the relevant parts of the new
AC_PROG_CC_C99 macro to my aclocal.m4 to use it.  I used the version Roger
Leigh posted as a diff on December 2nd.

I noticed two issues:

I had to change the order in which flags were tried in order to test for
"C99-plus-extensions" before "strict-C99" as discussed.  For instance,
although -std=c99 was tried after -std=gnu99, it should also be tried after
-qlanglvl=extc99.  This probably doesn't practically matter for any current
compilers, but putting all extended flags before all strict flags increases
the chances that the right thing will happen with future tools.

Much more importantly, $ac_cv_prog_cc_c99 is set to 'no' if C99 cannot be
supported (That's all well and good.), but the string ' no' is appended to
$CC in this case, which makes pretty much all future attempts to compile
gratuitiously fail.  In my application, I'm requesting C99 support just to
improve the chances of C99 semantics being applied to my sourcecode; once
I've turned on C99 _if possible_, I go on to test for the individual
features I need.  Since these are conceivibly provided by compiler
extensions even outside of C99 mode, I want the compiler to keep worked even
if it's no C99.  So, in the case that $ac_cv_prog_cc_c99 is set 'no', $CC
should be left unchanged.

I doubt either of these points are controversial, so I hope whoever has
control over such things can incorperate them appropriately.  Thanks.

-Dan




reply via email to

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