More clearly expose/explain native and cross-build target information

[ncoghlan]

BPO	23966
Nosy	@warsaw, @doko42, @ncoghlan, @abadger, @zooba, @rkuska

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['type-feature'] title = 'More clearly expose/explain native and cross-build target information' updated_at = user = 'https://github.com/ncoghlan' ``` bugs.python.org fields: ```python activity = actor = 'a.badger' assignee = 'none' closed = False closed_date = None closer = None components = [] creation = creator = 'ncoghlan' dependencies = [] files = [] hgrepos = [] issue_num = 23966 keywords = [] message_count = 3.0 messages = ['241129', '241229', '241711'] nosy_count = 8.0 nosy_names = ['barry', 'doko', 'ncoghlan', 'a.badger', 'Arfrever', 'bkabrda', 'steve.dower', 'rkuska'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue23966' versions = ['Python 3.5'] ```

[ncoghlan]

Discussion of bpo-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 bpo-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)

[ncoghlan]

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. bpo-23969 covers accurately capturing Mac OS X details, while bpo-23670 covers iOS. (bpo-23496 should also likely take the bpo-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 bpo-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).

[526a9556-0b1e-466b-8760-d36ea509066e]

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.