Conversation
| bazel_dep(name = "bazel_features", version = "1.32.0") | ||
| bazel_dep(name = "bazel_skylib", version = "1.8.2") | ||
| bazel_dep(name = "platforms", version = "1.0.0") | ||
| bazel_dep(name = "rust_toolchains", version = "0.68.1") |
There was a problem hiding this comment.
Nit: there's an existing convention on BCR to prefix instead, so toolchains_rust ?
There was a problem hiding this comment.
I don't have a super strong opinion on this bikeshed, i just want it built. That said, if you take a look at https://registry.bazel.build/search?q=toolchains you'll see that:
- 5 CC toolchains followed this convention (and toolchains_llvm_boostrapped only did because we were strongly urged, it will get renamed though)
- 5 CC toolchains did
xxx_toolchaininstead proto_toolchainsalso followed it, probably because you/Fabian picked the name :)- No other language did anything like this
So it doesn't feel like we necessarily need to draw a trend from a few isolated points, we should just pick whatever name is clearest IMO
| @@ -0,0 +1,5 @@ | |||
| package(default_visibility = ["//visibility:public"]) | |||
|
|
|||
| toolchain_type( | |||
There was a problem hiding this comment.
Should we comment explicitly that these are all meant to resolve to the exec platform? I dunno why it would be useful to have target-platform for these tools but I can imagine the feature request
There was a problem hiding this comment.
BTW, I can imagine a scenario where your target platform is meant for execution. Imagine you are building dev VM images or similar and want to package a compiler.
There was a problem hiding this comment.
Yes and you could also have clippy run as a test, and use target platform for tests.
There was a problem hiding this comment.
Let's get this landed first to unblock progress and then we can do target-platform toolchains as a followup
dzbarsky
force-pushed
the
rust_toolchains
branch
from
2bff4ff to
a31c639
Compare
dzbarsky
force-pushed
the
rust_toolchains
branch
from
a31c639 to
928c1c1
Compare
meteorcloudy
requested review from
UebelAndre,
illicitonion and
meteorcloudy
2 participants
This unblocks alternative rulesets from providing their own toolchain definitions while reusing rules_rust for compilation. Also it lays groundwork for splitting cargo and clippy to their own toolchains, so we can slim down rustc toolchain and optimize fetches