Configuring compiler and linker flags in rules_rust currently relies heavily on imperative Starlark code (such as hardcoded args.add blocks inside the rule implementation) and bespoke build settings/transitions. Because flag-building is tightly coupled with the rule logic, consumers face high friction when adapting toolchain configurations to custom environments.
To resolve these customization barriers, compile and link flags should be decoupled from the core rule implementation and exposed as declarative configurations at the toolchain level.
- Enable declarative wrappers and flags without maintaining rule forks: Users should be able to inject custom compiler/linker wrappers, extra flag configurations, or alternative platform sanitizers declaratively at the toolchain level. This enables setting flags for project-specific workflows rather than adding more build settings directly to
rules_rust, eliminating the need to carry custom patches or fork core rules (like rustc.bzl) and greatly simplifying upstream version upgrades.
- Support granular flag controls and custom compilation actions: The system should expose specific compilation sub-phases so that consumers can apply flags selectively based on the action type - such as targeting metadata-only builds (
.rmeta), clippy checkout runs, etc. It should also enable support for spawning different types of compilation actions, such as emitting LLVM IR (--emit=llvm-ir) or LLVM bitcode (--emit=llvm-bc), based on user demands.
- Provide configurable and overridable artifact naming: Hardcoded platform-specific name mappings (like
.rlib to .a static library symlinks or MSVC .dll vs. .dll.lib import conventions) should be decoupled and made configurable, making it easy to support custom platform layouts and exotic execution environments.
Configuring compiler and linker flags in
rules_rustcurrently relies heavily on imperative Starlark code (such as hardcodedargs.addblocks inside the rule implementation) and bespoke build settings/transitions. Because flag-building is tightly coupled with the rule logic, consumers face high friction when adapting toolchain configurations to custom environments.To resolve these customization barriers, compile and link flags should be decoupled from the core rule implementation and exposed as declarative configurations at the toolchain level.
rules_rust, eliminating the need to carry custom patches or fork core rules (likerustc.bzl) and greatly simplifying upstream version upgrades..rmeta),clippycheckout runs, etc. It should also enable support for spawning different types of compilation actions, such as emitting LLVM IR (--emit=llvm-ir) or LLVM bitcode (--emit=llvm-bc), based on user demands..rlibto.astatic library symlinks or MSVC.dllvs..dll.libimport conventions) should be decoupled and made configurable, making it easy to support custom platform layouts and exotic execution environments.