Jeroen Demeyer on Sat, 06 Sep 2008 19:34:31 +0200

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

Header files and Configure

Starting new thread about a different but related issue...

Bill Allombert wrote:
The symbol __GNUC__ is checked in _public_ headers file. This is
necessary, because once PARI is configured, build and installed
with one compiler, users might very well compile PARI programms
with _another_ compiler, and it would be wrong to assume both compilers
have the same features.

In practice it is common for users to build PARI with gcc (since it is
the default) and then build PARI programms with g++, so PARI headers
need to be compatible with both compilers even though there are subtle
differences in features.

Karim Belabas wrote:
I agree the #ifdef UNIX *must* be fixed, but this is a very small scale
project compared to fully switching to autoconf (about one or two hours ?).

The __GNUC__ is [ in all but one silly case to cater for old broken HPUX
headers ] about allowing GNU C [ = ({...}) ] macros  and is perfectly
appropriate, I think.

Let me be "bold" again and propose the following: remove all instances of #ifdef __GNUC__ and instead use #ifdef HAVE_GNU_STYLE_MACROS or something like that. Then in paricfg.h you can do
#ifdef __GNUC__
I think this is much more transparent, you concentrate the "detecting" part in just one place. Also, if I have a compiler which understands GNU-style macros but does not define __GNUC__, I can easily define HAVE_GNU_STYLE_MACROS myself.

Second, when building PARI itself we have [Cc]onfigure so we know which compiler we are using and we CAN check whether (for example) GNU style macros are supported. In this situation, you would have two different versions of paricfg.h: one for building PARI where we let [Cc]onfigure detect everything and one public header where we guess conservatively. Of course, what I said here also applies for detecting inline functions, detecting header files,...