Allow overriding python platform with _PYTHON_HOST_PLATFORM env var

[messense]

Useful for cross compilation.

See also

• https://wiki.debian.org/Python/MultiArch

[FeodorFitsner]

I've been about to post the same issue :)

TLDR: Despite _PYTHON_HOST_PLATFORM is kind of undocumented variable used in soon-to-be-deprecated-distutils I also think it could be the easiest way to fix tags for cross-compiled wheels.

Long version:

Re: #2102 (comment) and #2103.

According to PEP-730 and PEP-738 wheels tags should be:

Android:

• android_21_arm64_v8a
• android_21_armeabi_v7a
• android_21_x86_64
• android_21_x86

iOS:

• ios_12_0_arm64_iphoneos
• ios_12_0_arm64_iphonesimulator
• ios_12_0_x86_64_iphonesimulator

This should be the value returned by sysconfig.get_platform() (with _ replaced to -).

After looking at Maturin code base I see there are at least two ways for that value to get into the program:

• CARGO_BUILD_TARGET variable (or --target option).
• target.detect_arch_from_python() method

CARGO_BUILD_TARGET expects a valid triple in the format {arch}-{vendor}-{os}[-env], so neither android_21_arm64_v8a, not ios_12_0_arm64_iphoneos won't work there.

On the other hand detect_arch_from_python() is currently tailored to macOS only (btw, python interpreter detection code refuses executable name without a version on the end - could be fixed as well). We could, potentially, add checks/parsing for iOS and Android, but Target structure would need to be extended with os_ver (or something) field to store 12.0 for iOS and 21 for Android. Also, build_context.get_platform_tag() would need to be improved to handle iOS and Android OSes.

So, checking _PYTHON_HOST_PLATFORM and using it for a wheel tag would be an easiest way to satisfy custom tags requirements :)

I can try implementing that and submit a PR.

[messense]

Pull requests are welcome!

On the other hand detect_arch_from_python() is currently tailored to macOS only

Don't worry about this one, it's only for native macOS compilation.

[FeodorFitsner]

@messense what do you think about #2122? I don't have much experience with Rust, please let me know if it could be made more elegantly.

The implementation is that easy indeed, worked like a charm for us.

[messense]

#2122 looks good to me, thanks!