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.