One of our politicians famously uttered "life wasn't meant to be easy" - how right he was :) Let's assume I am trying to use distutils from Python 2.4 to package an installation for both Python 2.3 and Python 2.4 (or vice-versa - trying to use 2.3 distutils to package them both). As mentioned her previously, I want to do this so I can use the features in later versions of distutils (such as the post-install-script) to package extensions for earlier versions of Python. The installation script uses PyRun_SimpleFile. This takes a FILE *. The problem is that Python 2.3 and Python 2.4 use different runtime libraries. One of them is guaranteed to crash. This violates the Python rule that Python and its extensions must use the same CRTL. I see 2 choices: * Avoid PyRun_SimpleFile, by reading the file ourself, and using PyRun_SimpleString. This should work, but is fragile, as we are still breaking that rule. * Provide 2 different wininst.exe stubs, one for MSVC6 and one for MSVC7. distutils hardcodes the knowledge of what one to use for what version. However, the problem is that this will mean people building distutils to ship will always need *both* VC6 and VC7 - VC6 just for that stub, and VC7 to build everything else. The first option is less work, and should work today, but is still naughty. Any thoughts? Mark.
Mark Hammond wrote:
One of our politicians famously uttered "life wasn't meant to be easy" - how right he was :)
Let's assume I am trying to use distutils from Python 2.4 to package an installation for both Python 2.3 and Python 2.4 (or vice-versa - trying to use 2.3 distutils to package them both). As mentioned her previously, I want to do this so I can use the features in later versions of distutils (such as the post-install-script) to package extensions for earlier versions of Python.
The installation script uses PyRun_SimpleFile. This takes a FILE *. The problem is that Python 2.3 and Python 2.4 use different runtime libraries. One of them is guaranteed to crash. This violates the Python rule that Python and its extensions must use the same CRTL.
I see 2 choices: * Avoid PyRun_SimpleFile, by reading the file ourself, and using PyRun_SimpleString. This should work, but is fragile, as we are still breaking that rule. * Provide 2 different wininst.exe stubs, one for MSVC6 and one for MSVC7. distutils hardcodes the knowledge of what one to use for what version. However, the problem is that this will mean people building distutils to ship will always need *both* VC6 and VC7 - VC6 just for that stub, and VC7 to build everything else.
The first option is less work, and should work today, but is still naughty. Any thoughts?
Just to understand this: will this mean that you have to have VC7 in order to build extensions for Python 2.4 and onwards ? I think it is worthwhile (and have always argued that way) to have one distutils version which can create Python distributables for various Python versions, including as many older versions as possible. Does the move to VC7 mean that we'll break this strategy with Python 2.4 distutils ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2004)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Just to understand this: will this mean that you have to have VC7 in order to build extensions for Python 2.4 and onwards ?
Officially, I think it will. Unofficially, it will remain like it does today - it *may* work (depending on if you try and use Python API functions that use FILE objects). IIRC, there used to be a problem of you implemented objects, as the malloc/free pairs happened in different CRTLs, but I think that in recent versions the macro-magic means they do match) A Python API function "PyFile_OpenFile()" would also solve this issue, but obviously that wouldn't exist in 2.3 or earlier, so doesn't help this specific case.
I think it is worthwhile (and have always argued that way) to have one distutils version which can create Python distributables for various Python versions, including as many older versions as possible.
I believe that is the intent. There is one other small issue I had trying to do this for win32all, but I will address that later.
Does the move to VC7 mean that we'll break this strategy with Python 2.4 distutils ?
Yes, unless we do as outlined in my mail. Mark.
"Mark Hammond" <mhammond@skippinet.com.au> writes:
One of our politicians famously uttered "life wasn't meant to be easy" - how right he was :)
Let's assume I am trying to use distutils from Python 2.4 to package an installation for both Python 2.3 and Python 2.4 (or vice-versa - trying to use 2.3 distutils to package them both). As mentioned her previously, I want to do this so I can use the features in later versions of distutils (such as the post-install-script) to package extensions for earlier versions of Python.
The installation script uses PyRun_SimpleFile. This takes a FILE *. The problem is that Python 2.3 and Python 2.4 use different runtime libraries. One of them is guaranteed to crash. This violates the Python rule that Python and its extensions must use the same CRTL.
I see 2 choices: * Avoid PyRun_SimpleFile, by reading the file ourself, and using PyRun_SimpleString. This should work, but is fragile, as we are still breaking that rule. * Provide 2 different wininst.exe stubs, one for MSVC6 and one for MSVC7. distutils hardcodes the knowledge of what one to use for what version. However, the problem is that this will mean people building distutils to ship will always need *both* VC6 and VC7 - VC6 just for that stub, and VC7 to build everything else.
The first option is less work, and should work today, but is still naughty. Any thoughts?
Since wininst.exe dynamically loads the Python dll (even different versions), it is already fairly limited in the Python api it can use. Avoiding the call to PyRun_SimpleFile is still an option. Isn't it fun to break the rules ;-) ? Thomas
Since wininst.exe dynamically loads the Python dll (even different versions), it is already fairly limited in the Python api it can use. Avoiding the call to PyRun_SimpleFile is still an option.
Isn't it fun to break the rules ;-) ?
I did find a couple of other issues with breaking these rules: * PyRun_SimpleFile does not allow you to specify the "filename", so tracebacks indicate "<string>". To get a filename means using additional "compile" functions too. * redirection of stdout/stderr don't work. wininst.exe sets *its* stdout/stderr OK, but Python itself is using a *different* stdout/stderr, so the reopen has no effect. Multiple exes may turn out to be less hassle in the long run (except for the person who needs to build wininst_vc6.exe and wininst_vc7.exe) And re the other thread about MSVC7 directories: I will update the patch to falling back to the registry to try and locate this directory - this seems like a reasonable approach, and should work in almost all cases. Mark.
"Mark Hammond" <mhammond@skippinet.com.au> writes:
Since wininst.exe dynamically loads the Python dll (even different versions), it is already fairly limited in the Python api it can use. Avoiding the call to PyRun_SimpleFile is still an option.
Isn't it fun to break the rules ;-) ?
I did find a couple of other issues with breaking these rules: * PyRun_SimpleFile does not allow you to specify the "filename", so tracebacks indicate "<string>". To get a filename means using additional "compile" functions too.
* redirection of stdout/stderr don't work. wininst.exe sets *its* stdout/stderr OK, but Python itself is using a *different* stdout/stderr, so the reopen has no effect.
Multiple exes may turn out to be less hassle in the long run (except for the person who needs to build wininst_vc6.exe and wininst_vc7.exe)
Ok, doesn't sound like too much fun anymore. I'll take the multi exe approach.
And re the other thread about MSVC7 directories: I will update the patch to falling back to the registry to try and locate this directory - this seems like a reasonable approach, and should work in almost all cases.
Tim Peters reported that MSVC7 cannot be installed on win98, so this limits the variations that have to be supported. Thomasa
participants (3)
-
M.-A. Lemburg -
Mark Hammond -
Thomas Heller