[Python-Dev] use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings (original) (raw)
Skip Montanaro skip at pobox.com
Thu Aug 5 23:29:21 CEST 2004
- Previous message: [Python-Dev] OK to lower timeout for test_timeout's testConnectTimeout test?
- Next message: [Python-Dev] use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I really hate to disrupt this scintillating function decorator discussion...
At work the goal for our C++ build environment is "no warnings with gcc -Wall". We are not there yet (and thankfully I am not a participant in that particular holy grail), but those involved in that effort encountered a warning the other day generated because _XOPEN_SOURCE is defined in pyconfig.h. Unfortunately GCC also defines it, so a "macro redefined" warning is emitted when compiling with GCC and including Python.h.
I'm not about to suggest that the _XOPEN_SOURCE definition be removed from pyconfig.h.in. I trust that Martin v. Löwis and others involved have good reasons to leave it in. Perhaps adding
#pragma GCC system_headerto pyconfig.h.in would be acceptable though. This tells GCC that the file it appears in is a system header file and to not bitch about trivial stuff like macro redefinitions. This suggestion comes from one of the C++ experts here. I would never have figured it out myself. The scope of the pragma is only the file in which it appears, and it doesn't take effect for even that file until it's first encountered. This suggests that perhaps a slight restructuring of pyconfig.h.in would help to reduce its effect even more:
<all macros which don't start with "_">
#pragms GCC system_header
<all macros which do start with "_">(Pyconfig.h.in is almost there now.)
Some exceptions to the above structure might be necessary if the definition of a macro in the first group is conditioned on the value of a macro from the second group. I don't believe this is the case, at least not at the moment. It's unlikely to ever be the case since any smarts for such tests more appropriately belong in the configure script (or would be hand-coded on non-configure-type platforms).
I've adjusted my local copy of pyconfig.h.in and am building CVS HEAD and the 2.3 maintenance branch on both Solaris and MacOSX to see if any problems arise. I'd appreciate some feedback on whether or not this is deemed a reasonable idea though.
Thx,
Skip
- Previous message: [Python-Dev] OK to lower timeout for test_timeout's testConnectTimeout test?
- Next message: [Python-Dev] use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]