[Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

[Steve Dower]

As part of adding ARM32 support for Windows, we need to enable 
cross-compilation in distutils. This is easy enough, though it requires 
somehow getting the target platform as well as the current platform.

Right now, the change at https://github.com/python/cpython/pull/11774 
adds a get_target_platform() function for this and updates (as far as I 
can tell) all uses of get_platform() to use this instead. I would rather 
just change get_platform() to return the target platform.

The current docs are somewhat vague on exactly what this function does, 
and I suspect have been mostly written from an "always build from 
source" mentality that may have implied, but not explicitly considered 
cross-compilation.

https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform

"Return a string that identifies the current platform. This is used 
mainly to distinguish platform-specific build directories and 
platform-specific built distributions."

So it says "current" platform, explicitly says that "os.uname()" is the 
source, but then goes on to say:

"For non-POSIX platforms, currently just returns sys.platform."

Which is incorrect, as sys.platform is always "win32" always but 
get_platform() already returns "win-amd64" for 64-bit builds.

And also:

"For Mac OS X systems the OS version reflects the minimal version on 
which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET 
during the build of Python), not the OS version of the current system."

So it seems like this function is already returning "the default 
platform that should be used when building extensions" - ignoring bugs 
in libraries that monkeypatch distutils, the "--plat-name" option should 
entirely override the return value of this function.

Given this, does it seem to be okay to have it determine and return the 
target platform rather than the host platform? Right now, that would 
only affect the new target of building for win-arm32, but I would also 
like to update the documentation to make it more about how this value 
should be used rather than where it comes from.

Any objections or concerns?

Cheers,
Steve