Target triple parsing incomplete

[m3rcuriel]

Target triples are unfortunately much more complicated than "either three or four things separated for a dash." More specifically, GNU explicitly allows you to leave out "unknown". This means that thumbv7em-none-eabihf is not only a valid target triple, but a valid target triple that Rust lists in supported platforms (admittedly Tier 3).

[m3rcuriel]

Note that #207 admits a partial solution but it is incomplete to force people to override whenever there are non perfectly organized target triples.

[sayrer]

Is there a place to read up on how these are parsed? For example "aarch64-fuschia" is also a Rust target triple.

[m3rcuriel]

I would describe gcc as a reasonable reference implementation, see https://github.com/gcc-mirror/gcc/blob/master/config.sub I don't think duplicating this is necessary since Rust behaves correctly, but the way rules_rust handles constraints would require something like this.

…

On Wed, Mar 13, 2019, 20:59 RS ***@***.***> wrote: Is there a place to read up on how these are parsed? For example "aarch64-fuschia" is also a Rust target triple. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#206 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AI1Vm5toZ0frZhNql_fHPA-_FoxS-F1mks5vWZ8BgaJpZM4bx9ak> .

[sayrer]

hmm, how could that script output "aarch64-fuschia"?

I did mention that directly, and it's listed here: https://forge.rust-lang.org/platform-support.html

[m3rcuriel]

https://github.com/gcc-mirror/gcc/blob/master/config.sub#L1365

While I am not studied in the exact mechanisms of this subroutine, I'm going to assume that it works since fuschia is listed as a valid system.

The way this script (I believe) works is by taking the first piece of the triple and saying "does this match any of my architectures" followed by vendors, systems, ABI.

The config.sub script takes aarch64-fuchsia, and outputs aarch64-unknown-fuchsia, which is correct as the script exists to map the really strange world of target triples into always-sane three or four item ones -- the ones that rules_rust expects, not the ones Rust expects.

Note:

$ rustc --target=aarch64-unknown-fuchsia
error: Error loading target specification: Could not find specification for target "aarch64-unknown-fuchsia"
  |
  = help: Use `--print target-list` for a list of built-in targets

So tl;dr Rust does things its own way, which might beg a ticket for upstream, and config.sub exists to convert "weird" target triples into parse-able ones.

As an aside, a possible mitigation of this problem is to just distribute or pull config.sub, and run it on the target. rustc still gets passed the original target passed by the user, which is Rust-valid, but when rules_rust parses constraints out of it it uses the "fixed" form.

Either way, I'm not sure that trying to handle this perfectly for the user is worthwhile, and the current imperfect handling should then be documented. For my use-case I'm probably just going to have to write the rules that rules_rust generates myself, and maybe that's the right thing to recommend instead of going in and putting work into mapping between a colloquial understanding of a target triple and Rust's target triples.

[sayrer]

It seems like you're making the point that there isn't a sane specification here. Some terrible GNU shell script is probably not the answer.

"The config.sub script takes aarch64-fuchsia, and outputs aarch64-unknown-fuchsia"
...
"Could not find specification for target 'aarch64-unknown-fuchsia'"

Maybe these strings are useful to give some context to maintainers, but it seems like they are opaque identifiers.

[m3rcuriel]

The output of config.sub is a non-opaque identifier since it has the form vendor[sub]-system-os[-abi] I agree that the abbreviated ones such as aarch64-fuchsia are very opaque unless you know that fuchsia is an OS and thus can infer from there.

My point boils down to:

• Rust can do whatever it wants
• Rust is using "conventional" target triples
• config.sub is an example of someone parsing those conventional triples into actual information, which is the information that rules_rust wants in order to generate constraint sets / Bazel rules
• rules_rust could do something like that, or something completely different, but the status quo is inconsistent.

If you look at #207 you might get some more context about what my individual goals because if anything I question the desire to parse the triples in rules_rust at all.

[acmcarther]

This issue came up (in my pending comment) in #240

I agree generally with the observations in this issue. Specifically:

1. The current implementation of target triple parsing in rules_rust is primitive
2. The decision to perform parsing is somewhat questionable (though, I have a lengthy justification[1])
3. It would be nice to offload the work of parsing the triple to something "standard"

The path forward here is not completely clear to me. It is probably tied to a more complete handling of platforms.

---

[1] Rust's notion of target triples are tied both to the problem of toolchain resolution, as well as the problem of dependency resolution. The toolchain resolution problem is somewhat conventional, while the dependency resolution problem is more Rust-specific. I've laid the problem out in long form in various places in this repo and in google/cargo-raze, but generally the reasoning goes:

1. Rust stdlib is small
2. So, users depend on third party crates
3. And dependencies between third party crates can be (and are) defined using all of the properties Cargo.toml permits[2]. Incidentally, this includes Rust's notion of target triples[3]
4. It is desirable for non-cargo tools to resolve and compile third party crates approximately the same way that Cargo does.
5. Given (2), (3), and (4), third party build tools need to work with Rust's notion of target triples

[2] https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
[3] https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

[m3rcuriel]

This issue came up (in my pending comment) in #240

I agree generally with the observations in this issue. Specifically:

1. The current implementation of target triple parsing in rules_rust is primitive
2. The decision to perform parsing is somewhat questionable (though, I have a lengthy justification[1])

A maybe sane approach is to make each triple a platform constraint. That will sound less insane in a few Bazel versions, I think.

3. It would be nice to offload the work of parsing the triple to something "standard"

The path forward here is not completely clear to me. It is probably tied to a more complete handling of platforms.

Extremely slowly, and in my obviously copious spare time I have been working on basically moving the current behavior to a default (pending picking something more sane) and letting users define their own stdlib/compiler/platform constraint sets without having to do quite as much work as just not using the repository rules we have in rules_rust.

At least this way we don't break anyone because Bazel doesn't have a corresponding platform constraint value (i.e me).

[1] Rust's notion of target triples are tied both to the problem of toolchain resolution, as well as the problem of dependency resolution. The toolchain resolution problem is somewhat conventional, while the dependency resolution problem is more Rust-specific. I've laid the problem out in long form in various places in this repo and in google/cargo-raze, but generally the reasoning goes:

1. Rust stdlib is small
2. So, users depend on third party crates
3. And dependencies between third party crates can be (and are) defined using all of the properties Cargo.toml permits[2]. Incidentally, this includes Rust's notion of target triples[3]
4. It is desirable for non-cargo tools to resolve and compile third party crates approximately the same way that Cargo does.
5. Given (2), (3), and (4), third party build tools need to work with Rust's notion of target triples

I agree; however if people are using Cargo.toml setups to build they're already not doing Bazel-specific things, and maybe we should just "standardize" to my much lampooned answer of using config.sub.

It is unfortunate, perhaps, that Rust has decided to not only use a mediocre-at-best way of specifying targets, but also doesn't use them in what I would describe as a standard way. Rust's target triples are literally maps to target configurations, and no intelligent "oh these are all linux targets" takes place as far as I can tell. Ideally they'd standardize those maps to map from config.sub (or equiv) output -> map so that we can all figure out what the longhand form of the abusive shorthand is. (see aarch64-fuschia vs aarch64-unknown-fuschia.

At risk of getting lynched from Rust land, GOOS and GOARCH are imo superior.

[2] https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
[3] https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies