This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: MSVC6/7 issues with bdist_wininst and --target-version
Type: Stage:
Components: Distutils Versions: Python 2.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mhammond Nosy List: loewis, mhammond, theller
Priority: normal Keywords: patch

Created on 2004-07-01 03:26 by mhammond, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
bdist_wininst.patch mhammond, 2004-07-01 03:26 proposed patch
Messages (9)
msg46288 - (view) Author: Mark Hammond (mhammond) * (Python committer) 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) * (Python committer) Date: 2004-07-01 19:39
Logged In: YES 

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) * (Python committer) Date: 2004-07-01 19:59
Logged In: YES 

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 ' 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 ' 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) * (Python committer) Date: 2004-07-01 23:19
Logged In: YES 

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) * (Python committer) Date: 2004-07-06 19:23
Logged In: YES 

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

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 rev 1.49.
msg46293 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-07-10 11:36
Logged In: YES 

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, and it will automatically
use the old distutils.
msg46294 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2004-07-10 13:47
Logged In: YES 

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 <wink>
msg46295 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2004-07-12 12:10
Logged In: YES 

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) * (Python committer) Date: 2007-08-21 01:11
Was open, but marked as "Fixed" - closing.
Date User Action Args
2022-04-11 14:56:05adminsetgithub: 40487
2004-07-01 03:26:25mhammondcreate