Are Target Triples formally defined somewhere?

help
1

The closest text I've found to formally describe target triples is in the cargo build docs:

The general format of the triple is <arch><sub>-<vendor>-<sys>-<abi>.

Which is a fine start, but it's not clear to me how one can distinguish the <arch> and <sub> prats, since there's no delimiter. Looking through the output of rustup target list, perhaps it doesn't matter? Should, say, wasm32 and wasm32v1 simply be considered as separate architecture values? IOW, just ignore the <sub> part? But then what's its point.

Also, is there a way to programmatically distinguish the different target tiers?

2 Likes
2

Target triples/tuples practically have to be treated as opaque identifiers; consider the division into parts to be a heuristic for human readability and what a new one should look like, not something that is parseable.

Code seeking to make decisions based on the target’s properties should use the conditional compilation options like target_arch and target_os, instead.

Also, is there a way to programmatically distinguish the different target tiers?

No. I don’t think you should, either; tiers are about the level of support[1] from the Rust project, not the target’s actual capabilities.

  1. in all of the senses of the word: “how much do we offer out-of-the-box”, “how well is this expected to work”, and “how much will we help you if this breaks” ↩︎

4 Likes
3

Hrm. I was less looking at what features I could use in a project than creating a filter-able list of targets to build. I made this GitHub action for Go platforms, which lets me filter against OS, arch, and whether its' "first class". I'd like to make something similar for Rust, where I could filter targets to, for example, exclude mobile platforms and WASM, and not to fail if a target isn't tier 1.

4

I see. I am not an expert here, but I think the best available way to programmatically retrieve this kind of information is going to be something like using rustc -Z unstable-options --print all-target-specs-json. It turns out that even contains tier information!

5

That's exactly that I was looking for, thanks! Unfortunately only works on the nightly toolchain for now.

6

Yes. Everything relating to target spec JSON is unstable, I believe; the only stable related feature is --print target-list.

1 Like
7

Yeah of course. I might be able to hack something together by regularly updating a copy of the all-target-specs-json in my project and then using --print target-list or rustup target list --quiet to filter it.