"Martin v. Loewis" wrote: > > > > Of course, doing so would be really stupid. Python.h *must* be the > > > first include, or things may break. > > > > Why should "things break" ? I've doing this for years in lots > > of Python extensions... > > Python.h configures the C library, e.g. for multi-threading (by > defining _REENTRANT) or LFS (by defining _FILE_OFFSET_BITS). > > If you include system headers before Python.h, you may find that > different headers are differently configured. In turn, compilation may > fail or produce bogus code. > > If the module itself compiles correctly, you may still find that it is > inconsistent with the python executable that is going to load it. Sure, but the wrapped lib's headers files will expect the same logic (they want to configure the C lib too; and for pretty much the same reasons Python does). In the end I think that you can't really say whether things break or not due to the order of the #includes (lib header or Python.h first) because both can make assumptions which may fail on way or another. I'd close this with "Works for me" :-) > > Back on topic: how are we going to get -DINET6 out of the > > Makefile ? > > I just committed a change. Saw that checkin. Thanks for fixing this. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4