
What's the reasoning behind putting -DINET6 into the default compiler options of the generic Makefile ? I'm just asking because such a define will be inherited by all extensions being compiled with distutils and the Makefile.pre.in setup process... sounds like trouble if you ask me. Shouldn't the define be placed into the pyconfig.h file or only in those extensions which need it ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

What's the reasoning behind putting -DINET6 into the default compiler options of the generic Makefile ?
I believe the sole reason is that the author of the patch didn't know how to get it into pyconfig.h. itojun recently confirmed that all uses of the INET6 can be replaced with ENABLE_IPV6, and that the define may go away. I hesitate to change that, though, since some of the IPv6 implementations *may* require that INET6 is defined when processing the "system" headers (not all IPv6 implementations we support actually come with the operating system).
What kind of trouble?
Shouldn't the define be placed into the pyconfig.h file or only in those extensions which need it ?
Wouldn't it cause the same trouble there? Regards, Martin

"Martin v. Loewis" wrote:
For Python's own use, it should suffice defining the symbol in pyconfig.h.
The symbol could enable some logic which may not be desired by the application, e.g. cause system includes to change, socket semantics of wrapped libs could also be affected etc.
No, because the pyconfig.h import is under extension control (e.g. you can first include the system or lib header files and only then import pyconfig.h). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

"Martin v. Loewis" wrote:
Why should "things break" ? I've doing this for years in lots of Python extensions... Back on topic: how are we going to get -DINET6 out of the Makefile ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

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.
Back on topic: how are we going to get -DINET6 out of the Makefile ?
I just committed a change. Regards, Martin

"Martin v. Loewis" wrote:
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" :-)
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/

What's the reasoning behind putting -DINET6 into the default compiler options of the generic Makefile ?
I believe the sole reason is that the author of the patch didn't know how to get it into pyconfig.h. itojun recently confirmed that all uses of the INET6 can be replaced with ENABLE_IPV6, and that the define may go away. I hesitate to change that, though, since some of the IPv6 implementations *may* require that INET6 is defined when processing the "system" headers (not all IPv6 implementations we support actually come with the operating system).
What kind of trouble?
Shouldn't the define be placed into the pyconfig.h file or only in those extensions which need it ?
Wouldn't it cause the same trouble there? Regards, Martin

"Martin v. Loewis" wrote:
For Python's own use, it should suffice defining the symbol in pyconfig.h.
The symbol could enable some logic which may not be desired by the application, e.g. cause system includes to change, socket semantics of wrapped libs could also be affected etc.
No, because the pyconfig.h import is under extension control (e.g. you can first include the system or lib header files and only then import pyconfig.h). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

"Martin v. Loewis" wrote:
Why should "things break" ? I've doing this for years in lots of Python extensions... Back on topic: how are we going to get -DINET6 out of the Makefile ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

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.
Back on topic: how are we going to get -DINET6 out of the Makefile ?
I just committed a change. Regards, Martin

"Martin v. Loewis" wrote:
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" :-)
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/
participants (2)
-
M.-A. Lemburg
-
Martin v. Loewis