Header files and Configure

[Jeroen Demeyer <jdemeyer@cage.ugent.be>]

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__
#define HAVE_GNU_STYLE_MACROS 1
#endif
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,...

Cheers,
Jeroen