Support custom constraints in toolchains

[m3rcuriel]

Bazel does not supply platforms for many architectures, specifically bare metal.

Therefore, based on the existing triple_to_constraint_set logic, we cannot parse things that do not have natively defined platforms within Bazel which relies on Rust and Bazel being in sync in an uncomfortable way.

My current solution to this will be implementing an override for the constraint/exec sets so that users can customize the platforms. It also solves #206 for me since I can just pass the target triple through to rustc and ignore all of the parsing.

[m3rcuriel]

Ugh now that I look at it more it might be worth it to widen the scope of this to include "current system doesn't work for target triples that straight up do not have stdlibs, i.e thumbv7em-none-eabi, my favorite example.

Considering this additional realization it may make sense for me to hack my way through ignoring all of the rust_repository_set helpers and doing it my own way since this is a lot of functionality to support for the rules package.

It isn't hard to not include the stdlib, but I have no idea what the interface would look like for indicating that for, for example, a x86_64-unknown-linux-gnueabi compiling for thumbv7em-none-eabi.

[wildarch]

In hopes of rules_rust supporting bare metal targets, I sent a PR to bazel to add none as one of the default operating system constraints: bazelbuild/bazel#7560. Their response is that since these constraint values are public, they should be defined in the workspace. If we want to support these kinds of targets, I think we should either overhaul the toolchain definition mechanism or define constraints for toolchains inside of rules_rust.

I have some patches for targeting thumbv7em-none-eabihf with rules_rust if you're interested 😉. Those work around this issue by defining a none constraint value in the rules themselves.

[m3rcuriel]

@wildarch yes I'd love to see those.

I agree with Bazel's response that those should be defined by the project, in fact that's what I'm pushing for in this and #206. I'm working on hacking it through myself as I described in the OP, but having a design direction before submitting a PR is nice.

[wildarch]

@m3rcuriel my hacky test setup is available on Github: https://github.com/wildarch/rules_rust_cross.

This showcases cross compilation to thumbv7em-none-eabihf and also throws procedural macros into the mix. All the code is pretty trivial, but the patches in external/rules_rust.patch might be worth taking a look at

[m3rcuriel]

@wildarch looks great. Do you want to take this offline since it seems like we're working on some of the same stuff?

[wildarch]

@m3curiel sure! How would you prefer?

[m3rcuriel]

You can email me at lee.mracek@gmail.com.

[m3rcuriel]

In case anyone cares about an update to this, I have a hack I've been using locally but I'm basically waiting for 0.29 / 1.0 once platforms are better-configurable. Then it'll be ezpz to get this integrated.

[hlopko]

Hi all,

What's the status of this issue (now that we have Bazel >1.0 released)?
What exactly is missing on the Bazel side?
What is missing on the rules_rust side?

I might be able to help. Thanks!