I wrote:
> Many of the distutils "commands" use
> distutils.util.get_platform() as the
> basis for file and directory names used to package up extensions. On
> Windows, this returns the value of sys.platform. On all
> (desktop) Windows versions, this currently returns 'win32'.
>
> This causes a problem when trying to create a 64bit version
> of an extension.
> For example, using bdist_msi, the pywin32 extensions end up
> with a filename
> of 'pywin32-211.win32-py2.5.msi' for both 32bit and 64bit
> versions. This is not desirable for (hopefully) obvious
> reasons.
>
> I'd like to propose that an (untested and against 2.5) patch
> similar to the following be adopted in distutils:
Thanks to all for the comments so far. It seems that there are no real
objections, nor any real barriers to making this change. While Philip's
notes regarding dependencies are well founded, I believe its clear that no
dependencies are possible between 32 and 64bit versions for Windows, so
there are no broader architectural requirements that would block us moving
ahead with this.
Tres rightly points out that the name of the OS should be embedded in the
name of the package - so rather than including a new patch, I will simply
propose the specific strings that should be returned. Specifically, I
propose that distutils.util.get_platform return the following:
* On 32bit Windows, continue to return 'win32'.
* On 64bit windows, return a string of the format 'win64-{architecture}'
A good value for 'architecture' isn't clear. Either 'AMD' or 'Itanium'
appeals at first glance, but I'm a little concerned that (say) a "casual"
user with a new Intel Core Duo processor will not know they should use
something labelled as "AMD" (eg, "I explicitly asked for an Intel chip, not
an AMD one"). An alternative could be be 'x64' or 'i64', but I'm not sure
that casual user would be any better off, and with only a single letter
distinguishing them, there is scope for confusion. On my final (mutant)
hand, it seems that Itanium will be a historical footnote and demand for
Itanium 64bit packages will be tiny (I've had a reasonable number of
requests for x64 versions of pywin32, but zero for i64), so I doubt many
packages will bother with Itanium.
So, I'm leaning towards 'win64-x64' and 'win64-i64', with the expectation
that the 'i64' variant will be rarely seen in the wild. Alternatively,
'win-x64' and 'win-i64' appear reasonable - it doesn't seem necessary that
'64' appear twice in the name.
Depending on the feedback (or even lack of, which I'll take as meaning there
are no objections to my proposal), I'll create a patch, solicit review, and
assuming no further objections, check the changes in to the trunk.
All comments welcome!
Cheers,
Mark
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
