Remove "current" Windows executables from Lib/distutils/command in svn?
As I was preparing to check-in my cross-compilation patch, which includes a new x64 executable in the Lib/distutils/command directory, it occurs to me that we don't actually need it in subversion - and nor do we need wininst-9.0.exe. I believe these executables are in svn for historical reasons. The build process for these executables are now integrated into the core Python build process (although they are disabled by default). There is a good use-case for keeping executables built with older MSVC versions, but I don't see one for executables built with the current version. I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and enable the building of that project by default in the standard build process (and I'll setup the x64 build of the executable similarly). They will then need to be re-added when a future version moves away from Visual Studio 2008, but that seems like a reasonable way to approach things. Are there any objections to this, or should we stick with the status-quo and I'll add the new x64 executable? Or do things that way *just* for x64? Thanks, Mark.
I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and enable the building of that project by default in the standard build process (and I'll setup the x64 build of the executable similarly).
There are two issues here: a) how does the binary get into the release tarball? You might argue that it doesn't have to, as it is sufficient when it is included in the Windows installer, however, as currently implemented, bdist_wininst also runs on Unix, and people use it that way. b) IIRC, upx was used to compress these executables. I don't think the the current build process covers this, yet (but then, the current binaries might not be compressed with upx anymore, either - not sure whether that would be a bug). Of course, upx would probably not currently apply to Win64-amd64. As another alternative to providing a separate AMD64 binary, you could also try to make the existing binary work properly on Win64, and tell it with a config flag whether to look for Win32 or Win64 (or either) on the target system. Regards, Martin
As another alternative to providing a separate AMD64 binary, you could also try to make the existing binary work properly on Win64, and tell it with a config flag whether to look for Win32 or Win64 (or either) on the target system.
I'm afraid that isn't an option for me in the short term. Should I just check-in my cross-compilation patch as it stands then? Mark
As another alternative to providing a separate AMD64 binary, you could also try to make the existing binary work properly on Win64, and tell it with a config flag whether to look for Win32 or Win64 (or either) on the target system.
I'm afraid that isn't an option for me in the short term. Should I just check-in my cross-compilation patch as it stands then?
Sure, go ahead. Regards, Martin
On 06/04/2008, at 2:15 AM, Martin v. Löwis wrote:
a) how does the binary get into the release tarball? You might argue that it doesn't have to, as it is sufficient when it is included in the Windows installer, however, as currently implemented, bdist_wininst also runs on Unix, and people use it that way.
It would be a shame to lose this ability. It's very handy. d
Martin v. Löwis schrieb:
I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and enable the building of that project by default in the standard build process (and I'll setup the x64 build of the executable similarly).
There are two issues here: a) how does the binary get into the release tarball? You might argue that it doesn't have to, as it is sufficient when it is included in the Windows installer, however, as currently implemented, bdist_wininst also runs on Unix, and people use it that way. b) IIRC, upx was used to compress these executables. I don't think the the current build process covers this, yet (but then, the current binaries might not be compressed with upx anymore, either - not sure whether that would be a bug). Of course, upx would probably not currently apply to Win64-amd64.
I did not compress them with upx anymore because of licensing issues with the upx-created executables, but I do not remember the details anymore. Thomas
Martin v. Löwis schrieb:
b) IIRC, upx was used to compress these executables. I don't think the the current build process covers this, yet (but then, the current binaries might not be compressed with upx anymore, either - not sure whether that would be a bug). Of course, upx would probably not currently apply to Win64-amd64.
The 9.0 binary hasn't been compressed with upx (yet). Christian
participants (5)
-
"Martin v. Löwis" -
Christian Heimes -
David Arnold -
Mark Hammond -
Thomas Heller