httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: Bumping autoconf AC_PREREQ to 2.60?
Date Sun, 13 Jun 2010 18:16:51 GMT


On 06/13/2010 02:16 PM, Rainer Jung wrote:
> On 13.06.2010 13:29, Ruediger Pluem wrote:
>>
>>
>> On 06/12/2010 09:07 PM, Stefan Fritsch wrote:
>>> On Friday 11 June 2010, Ruediger Pluem wrote:
>>>>> Modified: httpd/httpd/trunk/configure.in
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
>>>>> 951893&r1=951892&r2=951893&view=diff
>>>>> ================================================================
>>>>> ============== --- httpd/httpd/trunk/configure.in (original)
>>>>> +++ httpd/httpd/trunk/configure.in Sun Jun  6 16:54:51 2010
>>>>> @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
>>>>>
>>>>>   AC_PROG_CC
>>>>>   AC_PROG_CPP
>>>>>
>>>>>
>>>>> +dnl Try to get c99 support for variadic macros
>>>>> +AC_PROG_CC_C99
>>>>> +
>>>> This test is only present since autoconf>= 2.60.
>>>> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
>>>> there, but the error is non fatal.
>>>
>>> This means it is not a good idea to run buildconf on RH4/5, but a
>>> configure created somewhere else with autoconf 2.60 should work fine.
>>> So this mainly affects httpd developers.
>>>
>>> We can either bump AC_PREREQ to 2.60, making it impossible to run
>>> buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
>>> (about 200 lines) from autoconf 2.60 in httpd's build system. The
>>> current state seems like a bad idea, because of the potential to ship
>>> a broken configure in release tarballs.
>>>
>>> Preferences? Is anyone here developing on RHEL?
>>
>> I do so partly. This is why I came across this :-). What does
>> AC_PROG_CC_C99
>> really do? Not that I am suggesting to remove this call from configure.in
>> but what does it do? Does it change compiler parameters such that the
>> compiler
>> is switched into C99 mode? If yes isn't gcc by default?
>> So if this is true my idea would be if it would be possible to just call
>> AC_PROG_CC_C99 if autoconf is>= 2.60.
> 
> I'm jumping in here:
> 
>  -- Macro: AC_PROG_CC_C99
>      If the C compiler is not in C99 mode by default, try to add an
>      option to output variable `CC' to make it so.  This macro tries
>      various options that select C99 on some system or another,
>      preferring extended functionality modes over strict conformance
>      modes.  It considers the compiler to be in C99 mode if it handles
>      `_Bool', `//' comments, flexible array members, `inline', signed
>      and unsigned `long long int', mixed code and declarations, named
>      initialization of structs, `restrict', `va_copy', varargs macros,
>      variable declarations in `for' loops, and variable length arrays.
> 
>      After calling this macro you can check whether the C compiler has
>      been set to accept C99; if not, the shell variable
>      `ac_cv_prog_cc_c99' is set to `no'.
> 
> More concrete it tries to compile a c99 program using the given CC and
> optionally with the flags -std=gnu99 -std=c99 -c99 -AC99 -xc99=all
> -qlanglvl=extc99 until it eventually works. Then it adds the needed flag
> to CC.
> 
> I'm using gcc 4.1.2 and there the macro adds -std=gnu99 to CC in
> build/config_vars.mk.
> 
> Stefan: The discussion thread I cited also contains the info how to use
> the directive only if it exists:
> 
> ifdef([AC_PROG_CC_C99], [AC_PROG_CC_C99])

+1 to this solution.
-0.5 on importing the code for AC_PROG_CC_C99 in configure.in

Regards

RĂ¼diger



Mime
View raw message