From: Mark Hammond
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)
I believe that mingw will build extensions which work with Python 2.3 and 2.4, because mingw supports both MSVC runtimes. You still have to build the extension using distutils from the appropriate Python version (ie, you need 2 Python versions installed).
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.
According to Martin von Loewis, this is a lost cause - mixing runtimes is never OK, even if you don't use "dangerous" functions (like ones which use FILE*). However, in practical terms, I've never generated a problem (although I haven't tried very hard).
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.
I may be misunderstanding what is being discussed here, but I believe that with the move to VC7, you will need the following to build extensions compatible with both Python 2.3 and 2.4:
1. Installed copies of both Python 2.3 and 2.4. 2. EITHER MSVC 6 and 7 (both versions) OR mingw
But I am probably missing something, as once you have the 2 versions of Python installed, I don't see the value in using a single shared distutils, rather than the one that comes with each Python.
teaching-my-grandmother-to-suck-eggs-ly y'rs Paul.
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.
According to Martin von Loewis, this is a lost cause - mixing runtimes is never OK, even if you don't use "dangerous" functions (like ones which use FILE*). However, in practical terms, I've never generated a problem (although I haven't tried very hard).
Yes, hence I never pursued it. "Although practicality beats purity" seems to apply, but I don't care enough to push it.
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.
I may be misunderstanding what is being discussed here, but I believe that with the move to VC7, you will need the following to build extensions compatible with both Python 2.3 and 2.4:
- Installed copies of both Python 2.3 and 2.4.
- EITHER MSVC 6 and 7 (both versions) OR mingw
Yes, that is true for all practical intent, if your installation has extension modules. However, for a pure-python distribution, you need *no* compilers installed. In that case, we still have a problem - at the moment, the installation is guaranteed to fail for either Python 2.3 and before, or for 2.4, depending on which CRTL was used to build wininst.exe.
To clarfify, I am talking about only how wininst.exe interacts with Python, not extension building related issues (even though they are similar).
Mark.
Moore, Paul wrote:
From: Mark Hammond
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.
I may be misunderstanding what is being discussed here, but I believe that with the move to VC7, you will need the following to build extensions compatible with both Python 2.3 and 2.4:
- Installed copies of both Python 2.3 and 2.4.
- EITHER MSVC 6 and 7 (both versions) OR mingw
But I am probably missing something, as once you have the 2 versions of Python installed, I don't see the value in using a single shared distutils, rather than the one that comes with each Python.
The latter would mean having to support 3-4 different distutils versions in your setup code. We already support 3-4 different Python versions (at Python and C level) and would like, if at all possible, to continue building all packages with one distutils version - the one in CVS which is the most up-to-date.
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
The latter would mean having to support 3-4 different distutils versions in your setup code. We already support 3-4 different Python versions (at Python and C level) and would like, if at all possible, to continue building all packages with one distutils version - the one in CVS which is the most up-to-date.
Just to throw one more minor spanner in the works, I believe I will be able to provide a patch that means you must *build* your extension with the Python version that the version targets - but can create a binary distribution, for any Python version, using a single distutils version (assuming it was previously built correctly)
I agree that in the future we should also allow you to build your extensions using the most recent, but that is far less critical when you consider other users - if someone other than the primary packager wants to build your package, they probably don't have the 'latest' distutils available to them.
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
Keeping the 'practicallity beats purity' theme, I agree. It means that whoever builds (and checks into CVS) wininst.exe must has *both* MSVC6 and MSVC7, but there is a good chance they will anyway.
Is there any reason wininst.exe is not itself built using distutils?
Mark.
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
Keeping the 'practicallity beats purity' theme, I agree. It means that whoever builds (and checks into CVS) wininst.exe must has *both* MSVC6 and MSVC7, but there is a good chance they will anyway.
Is there any reason wininst.exe is not itself built using distutils?
my assumption on the later is purely that if it was the user would HAVE to have a compiler installed - but if they are writing pure python extensions they *should* not need this as they are not likely to have it.
But maybe adding the functionality to force a build if building a C extension is a worthwhile thing??
Just to add my two pence to the debate...
-- Phil
"Requirements - what are they I just hack something together that does what I think they want" ;)
Mark Hammond wrote:
The latter would mean having to support 3-4 different distutils versions in your setup code. We already support 3-4 different Python versions (at Python and C level) and would like, if at all possible, to continue building all packages with one distutils version - the one in CVS which is the most up-to-date.
Just to throw one more minor spanner in the works, I believe I will be able to provide a patch that means you must *build* your extension with the Python version that the version targets - but can create a binary distribution, for any Python version, using a single distutils version (assuming it was previously built correctly)
That would be ideal.
I agree that in the future we should also allow you to build your extensions using the most recent, but that is far less critical when you consider other users - if someone other than the primary packager wants to build your package, they probably don't have the 'latest' distutils available to them.
True, but at least I can point at a place where to download and install it (not the CVS one, but latest released one).
I think that's a reasonable thing to ask from users if they want to build wininst packages that are different from the ones we distribute.
From source installations (still) work rather nicely across all distutils versions - at least on Unix platforms which is where people care about source installations. Windows folks are happy with the wininst installer, so it's a non-issue for those.
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
Keeping the 'practicallity beats purity' theme, I agree. It means that whoever builds (and checks into CVS) wininst.exe must has *both* MSVC6 and MSVC7, but there is a good chance they will anyway.
Is there any reason wininst.exe is not itself built using distutils?
No idea :-) That one is for Thomas to answer.
"Mark Hammond" mhammond@skippinet.com.au writes:
Is there any reason wininst.exe is not itself built using distutils?
At that time distutils couldn't build exe files, and since I had the workspace anyway I didn't care.
IIRC, Rene Liebscher posted a script to build wininst with distutils.
Thomas
Thomas Heller schrieb:
"Mark Hammond" mhammond@skippinet.com.au writes:
Is there any reason wininst.exe is not itself built using distutils?
At that time distutils couldn't build exe files, and since I had the workspace anyway I didn't care.
IIRC, Rene Liebscher posted a script to build wininst with distutils.
See http://mail.python.org/pipermail/distutils-sig/2001-April/002329.html
But it is probably not up to date.
Rene Liebscher
"M.-A. Lemburg" mal@egenix.com writes:
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
Yes, I think that's the best option. I will make this change as soon as I have time (I'm not *actually* using 2.4 already).
Thomas
Thomas Heller wrote:
"M.-A. Lemburg" mal@egenix.com writes:
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
Yes, I think that's the best option. I will make this change as soon as I have time
Great :-)
(I'm not *actually* using 2.4 already).
Same here.
We are building 2.4 versions of our packages for testing purposes every now and then, but only on Linux where we don't have the libc vs. glibc problem (anymore). For Linux the UCS4 vs. UCS2 build (ie. Redhat vs. the rest of the world) problem is a much more serious one, but that's a different topic.
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
Yes, I think that's the best option. I will make this change as soon as I have time
Great :-)
Thomas,
Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the resource id to change it...
I will try to put something together for you when I have some time...but I only have MSVC7.1 so I can't give you a project for MSVC6.
-- Phil
"Requirements - what are they I just hack something together that does what I think they want" ;)
Thomas,
Hmm this doesn't seem to have made it to the list but just incase it turns up in a bit...ignore it...I have got something working without a need to change the exe...
Could you explicity add an icon as the apps icon - as when I have looked
at the sources there isn't one - so it is
hard for me to write code to replace it - my earlier thread - if it
doesn't explicitly exist as I need to know the
resource id to change it...
I will try to put something together for you when I have some time...but I
only have MSVC7.1 so I can't give you a
project for MSVC6.
-- Phil
"Requirements - what are they I just hack something together that does what I think they want" ;)
"Phil Hornby" phil.hornby@accutest.co.uk writes:
Thomas,
Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the resource id to change it...
I would have added one if I would have found one that is really free to use legally. I have to admint that I don't care too much about the icon so I did not search very hard (if at all ;-).
I will try to put something together for you when I have some time...but I only have MSVC7.1 so I can't give you a project for MSVC6.
One problem you will face (and that is maybe an additional argument against making the icon changeable at runtime, when the distribution is built), is that the ...UpdateResource() functions from the win32 api are only available on NT/2000/XP, not Win95/98/Me. At least when Microsoft's unicows.dll is not available. And IMO unicows.dll license restrictions are not 'compatible' with the Python license to allow redistribution with Python or distutils.
Thomas
Thomas Heller wrote:
"Phil Hornby" phil.hornby@accutest.co.uk writes:
Thomas,
Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the resource id to change it...
I would have added one if I would have found one that is really free to use legally. I have to admint that I don't care too much about the icon so I did not search very hard (if at all ;-).
You should be able to use the snake icon that we use for the Python installer (basically the same as the favicon.ico we have on python.org). I think it's even included somewhere in the distribution... right under PC/pycon.ico.
I will try to put something together for you when I have some time...but I only have MSVC7.1 so I can't give you a project for MSVC6.
One problem you will face (and that is maybe an additional argument against making the icon changeable at runtime, when the distribution is built), is that the ...UpdateResource() functions from the win32 api are only available on NT/2000/XP, not Win95/98/Me. At least when Microsoft's unicows.dll is not available. And IMO unicows.dll license restrictions are not 'compatible' with the Python license to allow redistribution with Python or distutils.
"M.-A. Lemburg" mal@egenix.com writes:
Thomas Heller wrote:
"Phil Hornby" phil.hornby@accutest.co.uk writes:
Thomas,
Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the resource id to change it...
I would have added one if I would have found one that is really free to use legally. I have to admint that I don't care too much about the icon so I did not search very hard (if at all ;-).
You should be able to use the snake icon that we use for the Python installer (basically the same as the favicon.ico we have on python.org). I think it's even included somewhere in the distribution... right under PC/pycon.ico.
That looks the same (or very similar) to Python23\py.ico, which is associated with .py files.
IMO for an installer (even if it installs Python modules) the usual computer picture with a disc or a disc box beneath it is more appropriate.
If you look at the default py2exe icon you will notice that I'm very creative and good making custom icons ;-), so that's not an option.
Thomas
Thomas Heller wrote:
Could you explicity add an icon as the apps icon - as when I have looked at the sources there isn't one - so it is hard for me to write code to replace it - my earlier thread - if it doesn't explicitly exist as I need to know the resource id to change it...
I would have added one if I would have found one that is really free to use legally. I have to admint that I don't care too much about the icon so I did not search very hard (if at all ;-).
You should be able to use the snake icon that we use for the Python installer (basically the same as the favicon.ico we have on python.org). I think it's even included somewhere in the distribution... right under PC/pycon.ico.
That looks the same (or very similar) to Python23\py.ico, which is associated with .py files.
IMO for an installer (even if it installs Python modules) the usual computer picture with a disc or a disc box beneath it is more appropriate.
If you look at the default py2exe icon you will notice that I'm very creative and good making custom icons ;-), so that's not an option.
You could take one of these:
http://www-kp3.gsi.de/www/img/eit/eit_summary.html
"M.-A. Lemburg" mal@egenix.com writes:
[about icons for bdist_wininst installers]
You could take one of these:
Na, I don't really like them.
Thomas
"M.-A. Lemburg" mal@egenix.com writes:
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
I'm currently working on this.
distutils.msvccompiler.get_build_version() returns the MSVC version number as float, so I would suggest we name the wininst.exe according to this schema "wininst-%s.exe" % msvccompiler.get_build_version()
wininst-6.0.exe and wininst-7.1.exe binaries would be provided with python (and distutils, if this is distributed separately again).
Thomas
Thomas Heller wrote:
"M.-A. Lemburg" mal@egenix.com writes:
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
I'm currently working on this.
distutils.msvccompiler.get_build_version() returns the MSVC version number as float, so I would suggest we name the wininst.exe according to this schema "wininst-%s.exe" % msvccompiler.get_build_version()
wininst-6.0.exe and wininst-7.1.exe binaries would be provided with python (and distutils, if this is distributed separately again).
Sounds right to me.
"M.-A. Lemburg" mal@egenix.com writes:
Thomas Heller wrote:
"M.-A. Lemburg" mal@egenix.com writes:
That said, I think that including two wininst versions, one compiled with VC6, the other with VC7, would solve this problem nicely. You'd still have to have VC6/7 for compiling C extensions, but at least generating pure Python distutils wininst packages would remain possible.
I'm currently working on this. distutils.msvccompiler.get_build_version() returns the MSVC version number as float, so I would suggest we name the wininst.exe according to this schema "wininst-%s.exe" % msvccompiler.get_build_version() wininst-6.0.exe and wininst-7.1.exe binaries would be provided with python (and distutils, if this is distributed separately again).
Sounds right to me.
Just for the record: get_build_version() returns the integer '6' for VC6, and the float '7.1' for VC7.1, so the filenames will be 'wininst-6.exe' and 'wininst-7.1.exe'.
Thomas
I'm currently working on this.
distutils.msvccompiler.get_build_version() returns the MSVC version number as float, so I would suggest we name the wininst.exe according to this schema "wininst-%s.exe" % msvccompiler.get_build_version()
wininst-6.0.exe and wininst-7.1.exe binaries would be provided with python (and distutils, if this is distributed separately again).
Thomas
Sounds like a plan to me...
Phil
-
M.-A. Lemburg -
Mark Hammond -
Moore, Paul -
Phil Hornby -
René Liebscher -
Thomas Heller