<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 11:38 AM Steve Dower <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As part of adding ARM32 support for Windows, we need to enable <br>
cross-compilation in distutils. This is easy enough, though it requires <br>
somehow getting the target platform as well as the current platform.<br>
<br>
Right now, the change at <a href="https://github.com/python/cpython/pull/11774" rel="noreferrer" target="_blank">https://github.com/python/cpython/pull/11774</a> <br>
adds a get_target_platform() function for this and updates (as far as I <br>
can tell) all uses of get_platform() to use this instead. I would rather <br>
just change get_platform() to return the target platform.<br>
<br>
The current docs are somewhat vague on exactly what this function does, <br>
and I suspect have been mostly written from an "always build from <br>
source" mentality that may have implied, but not explicitly considered <br>
cross-compilation.<br>
<br>
<a href="https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform" rel="noreferrer" target="_blank">https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform</a><br>
<br>
"Return a string that identifies the current platform. This is used <br>
mainly to distinguish platform-specific build directories and <br>
platform-specific built distributions."<br>
<br>
So it says "current" platform, explicitly says that "os.uname()" is the <br>
source, but then goes on to say:<br>
<br>
"For non-POSIX platforms, currently just returns sys.platform."<br>
<br>
Which is incorrect, as sys.platform is always "win32" always but <br>
get_platform() already returns "win-amd64" for 64-bit builds.<br>
<br>
And also:<br>
<br>
"For Mac OS X systems the OS version reflects the minimal version on <br>
which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET <br>
during the build of Python), not the OS version of the current system."<br>
<br>
So it seems like this function is already returning "the default <br>
platform that should be used when building extensions" - ignoring bugs <br>
in libraries that monkeypatch distutils, the "--plat-name" option should <br>
entirely override the return value of this function.<br>
<br>
Given this, does it seem to be okay to have it determine and return the <br>
target platform rather than the host platform? Right now, that would <br>
only affect the new target of building for win-arm32, but I would also <br>
like to update the documentation to make it more about how this value <br>
should be used rather than where it comes from.<br>
<br>
Any objections or concerns?<br></blockquote><div><br></div><div>To alleviate confusion long term I'd love it if we could deprecate the unqualified get_platform() API and point people towards always being explicit about get_target_platform() vs get_current_platform().</div><div><br></div><div>There are valid reasons for people to be expecting either target or current return values from get_platform(), but I agree with you, having it return the target platform <i>feels</i> more likely to be what people want.  It'd be worth auditing a random sample of people's calls of this API in open source projects to confirm that intuition.</div><div><br></div><div>-gps<br></div></div></div>