Analog to cargo profiles in rules_rust

[djmarcin]

Currently it seems that the compilation mode is used to drive the opt_level and debuginfo settings at the toolchain level. This makes it extremely difficult to override settings for more than one crate at a time. For example, if I wanted to override -c opt to use "s" instead of 3, I would need to define an entirely new toolchain and figure out how to get my binaries to use it instead of the default toolchain.

This is substantially more difficult than cargo profiles. It would be nice if a profile-like option was exposed in the repository rules to allow the option to more easily change these options that apply across many crates at once. It would be ideal if such an option was able to be toggled by individual targets rather than globally. For example, we may want to have different optimization settings for code shipped to client devices vs cloud servers without needing to define custom toolchains for one or the other.

I'm not sure after skimming the bazel toolchain docs if this is really possible without defining multiple toolchains, but if not, it would be ideal if rules_rust could make this simpler with a helper rule to define additional toolchains by passing it a profile-like dict.

Looking for feedback on this idea / has it been thought about before? If so, are there ideas about how it might work?

[mattbonnell]

Late to the party.

I'm using rules_bazel in "direct packages"/Cargo.toml-free. We run a polyglot monorepo so being able to use pure Bazel and avoid bringing in language-specific build config formats is a big usability win for us.

That said, the ability to configure compilation profiles that Cargo.toml provides is noticeably absent in this setup. Curious how other folks in the community are working around this and what would need to be done to expose this sort of functionality in rules_rust. I have time and motivation to contribute in this area.