[Distutils] distutils.util.get_platform() for Windows

[Mark Hammond]

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:

Index: util.py
===================================================================
--- util.py     (revision 56286)
+++ util.py     (working copy)
@@ -29,8 +29,19 @@
        irix-5.3
        irix64-6.2

-    For non-POSIX platforms, currently just returns 'sys.platform'.
+    For Windows, the result will be one of 'win32', 'amd64' or 'itanium'
+
+    For other non-POSIX platforms, currently just returns 'sys.platform'.
     """
+    if os.name == 'nt':
+        # copied from msvccompiler - find the processor architecture
+        prefix = " bit ("
+        i = string.find(sys.version, prefix)
+        if i == -1:
+            return sys.platform
+        j = string.find(sys.version, ")", i)
+        return sys.version[i+len(prefix):j].lower()
+
     if os.name != "posix" or not hasattr(os, 'uname'):
         # XXX what about the architecture? NT is Intel or Alpha,
         # Mac OS is M68k or PPC, etc.

This will result in both the final version of most bdist_* installations
having the architecture in the filename.  It also has the nice side effect
of having the temp directories used by these commands include the
architecture in their names, meaning its possible to build multiple Windows
architectures from the same build tree, although that is not the primary
motivation.  Also note that bdist_msi has 'win32' hard-coded in one place,
where a call to get_platform() would be more appropriate, but I'm assuming
that is a bug (ie, bdist_msi should use get_platform() regardless of the
outcome of this discussion about what get_platform() should return)

Note that this issue is quite different than, but ultimately impacted by,
the cross-compiling issue.  Its quite different as even when building x64
natively on x64, 'win32' is used in the generated filename and this patch
fixes that.  It is impacted by cross-compiling, as it assumes the host
environment is the target environment - but so does the rest of that
function on all platforms.

Any objections?

Cheers,

Mark