Re: Bumping autoconf AC_PREREQ to 2.60?
On Monday 14 June 2010, William A. Rowe Jr. wrote: On 6/13/2010 7:33 AM, Stefan Fritsch wrote: If we want to support autoconf 2.59, it seems much easier to just backport the autoconf macro. And in that way, non-gcc users would benefit as well. Please report back on the licensing of that macro. You are right. Autoconf licensing exception covers only output of Autoconf which the macros are not. Therefore the macros are GPL and cannot be included into httpd. I will instead implement a warning that a newer version of autoconf is recommended.
Re: Bumping autoconf AC_PREREQ to 2.60?
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= 951893r1=951892r2=951893view=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. Regards Rüdiger
Re: Bumping autoconf AC_PREREQ to 2.60?
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= 951893r1=951892r2=951893view=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]) I think Stefan needs uses C99 in include/http_log.h via variadic macros (__VA_ARGS__). There, if the compiler is C99, the call to the log function is surrounded with an if checking the log level first (for efficiency). If the compiler is not C99, then it will jump always into the log function and only check the log level there. gcc when not used in C99 mode has another idiom for variadic macros, see e.g. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Variadic-Macros.html#Variadic-Macros But that way is not standardized. Regards, Rainer
Re: Bumping autoconf AC_PREREQ to 2.60?
On Sun, 13 Jun 2010, 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= 951893r1=951892r2=951893view=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. Yes, that's what it does, and no gcc still defaults to c89 by default (I am using gcc 4.4). Not having c99 will not cause any real functional problems for httpd. The created code will probably be slightly slower and the use of APLOG_MAX_LOGLEVEL is not possible without it. So, it's definitely not perfect to use autoconf 2.59 but for some people, it may still be preferable to having to install a new autoconf. I don't have 2.59 installed anywhere to test right now. If the lack of AC_PROG_CC_C99 just causes a warning, that may be acceptable. Or we may print a more readable warning that autoconf 2.60 is recommended using the IFDEF method outlined by Rainer. But I don't want to spend much energy for special handling of 2.59. If we want to support 2.59, we should just include the code for AC_PROG_CC_C99 in our configure script.
Re: Bumping autoconf AC_PREREQ to 2.60?
On Sun, 13 Jun 2010, Rainer Jung wrote: I think Stefan needs uses C99 in include/http_log.h via variadic macros (__VA_ARGS__). There, if the compiler is C99, the call to the log function is surrounded with an if checking the log level first (for efficiency). If the compiler is not C99, then it will jump always into the log function and only check the log level there. Exactly. gcc when not used in C99 mode has another idiom for variadic macros, see e.g. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Variadic-Macros.html#Variadic-Macros But that way is not standardized. If we want to support autoconf 2.59, it seems much easier to just backport the autoconf macro. And in that way, non-gcc users would benefit as well.
Re: Bumping autoconf AC_PREREQ to 2.60?
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= 951893r1=951892r2=951893view=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
Re: Bumping autoconf AC_PREREQ to 2.60?
On 6/13/2010 7:33 AM, Stefan Fritsch wrote: If we want to support autoconf 2.59, it seems much easier to just backport the autoconf macro. And in that way, non-gcc users would benefit as well. Please report back on the licensing of that macro.
Re: Bumping autoconf AC_PREREQ to 2.60?
On 12.06.2010 21:07, 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= 951893r1=951892r2=951893view=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? No problem for me. 2.59 is 6.5 years old, 2.60 4 years. Most recent is 2.65. The last time there was discussion about this (Nov 2008) http://marc.info/?t=12278719352r=1w=2 the result seems to have been to recommend 2.61. Regards, Rainer
