| msg46288 - (view) |
Author: Mark Hammond (mhammond) *  |
Date: 2004-07-01 03:26 |
| bdist_wininst attempts to use the correct MSVC runtime for the current version of Python. This doesn't work correctly when --target-version is set. In that case, bdist_wininst still uses the *current* sys.version (ie, 2.4) rather than the version specified as --target-version. Thus, the msvc7 runtime based executable stub is *always* used. This patch "hard-codes" knowledge of earlier Python versions, providing the correct result when Python 2.4 is used to build Python 2.3 and earlier distributions. As the comments in the patch mention, another alternative is to allow --target-version to specify a Python executable instead of a simple version string, and execute that Python to parse its sys.version. Let me know if you think that is a good/better idea. Assigning to Thomas for review, then please assign back. |
|
|
| msg46289 - (view) |
Author: Thomas Heller (theller) * |
Date: 2004-07-01 19:39 |
| Logged In: YES user_id=11105 The situation is even worse. --target-version is only available for pure-Python distributions which don't have extension modules, if you want to restrict the installer to only one version of Python, for whatever reason. I could never think of a reason, but now there is one: different MSVC runtimes used in the target Python. Running a Python executable to determine the MSVC runtime does not work: First, usually you build installers for other users, second, some people build windows installers on non-windows systems. I have no idea how this can be solved, except of a very old one of mine: build and execute the installer on the target system ;-) |
|
|
| msg46290 - (view) |
Author: Thomas Heller (theller) * |
Date: 2004-07-01 19:59 |
| Logged In: YES user_id=11105 Maybe bdist_wininst must be changed to (hard-coded) only accept 2.4 and higher when 2.4 is used to build the installer, and only accept 2.3 and lower otherwise? For the other idea (building the installer on the target system): we could run 'setup.py build_ext' on the source system, maybe repeat this for different Python versions if available, zip up the source and build tree (including compiled extensions), and then run 'setup.py bdist_wininst' on the target system, and then execute the exe? This would also allow to have cross version support, including extensions, in one installer file. |
|
|
| msg46291 - (view) |
Author: Mark Hammond (mhammond) * |
Date: 2004-07-01 23:19 |
| Logged In: YES user_id=14198 I'm not exactly sure what you are saying. The current version of bdist_wininst allows you to specify --target-version and --skip-build, thereby allowing this to target *any* version of Python. If target_version != sys.version, the package has extensions and --skip-build is not specified, an error is thrown. So, I *build* the extensions using the "native" version of Python, but want to *package* the installer using CVS trunk disutils. This last step has --skip-build specified, and works fine. So I can't see the problem you allude to. Further, it works just fine with my patch using Python 2.4 to package up my 2.3/2.2 based installers. Unfortunately, I'm not even sure if you are saying Python 2.4 distutils should be able to package 2.3/2.2 based packages. My idea of specifying the executable would be an option. My suggestion is that this would be used simply so Python could extract the sys.version for that version, and parse the C compiler used as it does now for the current version. It would simply allow disutils to extract more information about the target version than "x.y", and may allow us to better support non MS compilers (as a comment in the existing code mentions). Of course, if they are building without that target version available, then they can stick to supplying just the target version number, as now. |
|
|
| msg46292 - (view) |
Author: Thomas Heller (theller) * |
Date: 2004-07-06 19:23 |
| Logged In: YES user_id=11105 Ah, now I understand. I didn't even know that it was possible to use --target-version and --skip-build to build installers for other Python versions, but this is definitely cool. I checked in your patch to make sure it gets into 2.4a1. Your idea to specify an executable makes sense, but imo only when 2.4 is an old version, isn't it? Feel free to provide an additional patch for that, but I think one should still be able to use '2.3' as argument for the --target-version switch. BTW: The short variant of the --target-version switch (-v) conflicts with the --verbose option and doesn't work, so I'm taking this out as well. Checked in as bdist_wininst.py rev 1.49. |
|
|
| msg46293 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-07-10 11:36 |
| Logged In: YES user_id=21627 I'd like to mention that --target-version isn't really needed, IMO: it is relatively easy to just use the old Python executable to run setup.py, and it will automatically use the old distutils. |
|
|
| msg46294 - (view) |
Author: Mark Hammond (mhammond) * |
Date: 2004-07-10 13:47 |
| Logged In: YES user_id=14198 The point is to use a *new* distutils with an old Python version - ie, I want to use the latest distutils features to build a Python 1.5.2 distribution. OK, maybe not 1.5.2 anymore |
|
|
| msg46295 - (view) |
Author: Thomas Heller (theller) * |
Date: 2004-07-12 12:10 |
| Logged In: YES user_id=11105 Hm, it's not as cool as I thought - you only get the new distutils features from the bdist_wininst command, not from other commands. For example, the new 'package_data' option doesn't work for target-version 2.3, since the build tree is still created with the 2.3 distutils. |
|
|
| msg46296 - (view) |
Author: Mark Hammond (mhammond) * |
Date: 2007-08-21 01:11 |
| Was open, but marked as "Fixed" - closing. |
|
|