homepage

Discussion of issue 22980 made it clear to me that part of the problem with the cross-build support is that the difference between the build time information exposed in sysconfig and the live system information exposed in the platform module isn't clear.
Debian's multiarch triplets (https://wiki.debian.org/Multiarch/Tuples) describe this information well, but it currently isn't readily exposed to Python code. sysconfig.get_config_var("MULTIARCH") only works on Debian & derivatives, and even issue 22980 only exposes the information in sysconfig.get_config_var("SOABI") on a subset of platforms.
It would be good to extend the triples to cover Windows, and also to expose the *current* system triple at runtime in the platform module (including appropriate normalisation)

Capturing some additional notes regarding the purpose of multiarch platform triplets. These triplets should unambiguously capture:
* syscall ABI (~= kernel)
* instruction set (IA-32, IA-64, PowerPC, ARM, ARM64, etc)
* endian­ness (big- or little-
* word size (32- or 64-)
The initial set of triplets from Debian covers GNU/Linux, GNU/Hurd and GNU/FreeBSD. Issue 23969 covers accurately capturing Mac OS X details, while issue 23670 covers iOS. (Issue 23496 should also likely take the issue 22980 changes into account for the Android cross-build)
I've added Steve Dower to the nosy list as it would also be good to have a set of triplets defined for Windows. MAL suggested in issue 22980 that it may be worth capturing this ABI compatibility identification discussion as a PEP rather than solely as a set of issues with resulting changes to the documentation, which I think is a reasonable direction to go (even if it's done primarily as an after-the-fact communication of the build identification changes for inclusion in What's New, rather than a gating requirement for actually doing the work).

Note for doko/barry: The multiarch/Tuples page should have a section on how the MultiArch Tuples interact with hwcaps (or a link to such a section in a different document). The rationale for not using Gnu-Triplets in MulitArch/Tuples currently says that we do not want separate entries for (as an example) i386 vs i686 instructions but does not tell why.
https://wiki.debian.org/Multiarch/TheCaseForMultiarch#Mixed_ABIs_and_instruction_set_extensions says that the i386 vs i686 use case is probably better addressed by glibc's hwcaps but points back to MultiArch/Tuples for rationale.
A section of rationale and example to show how the multiarch tuple and hwcaps complement each other would fix that.