Brendan Hansknecht (Mar 02 2022 at 18:27): Brendan Hansknecht (Mar 02 2022 at 18:27):This is just an open end question since I don't have a solution and was hoping someone would have ideas.
Does anyone know how to do crate feature management better in a Rust workspace. I have 2 main complaints with our current setup:
cargo build from the root folder builds every crate with its default features. Some crates, like roc_std, are only meant to be built with their default features in specific circumstances. Specifically for roc_std, it is by default setup to compile into a platform. This means that when compiled alone, it has undefined symbols to roc_* functions that can break linking. Sure we can exclude roc_std from the workspace, but that fells more like a hack than a proper solution. Maybe we should make it so that cargo build on the workspace just compiles the roc_cli for the roc binary? That being said, if we just compile the roc binary, will that cause cargo test to only run the roc_cli tests by default? Hopefully there is a more correct solution.roc_build has features for each backend. It is also imported in a number of locations. If we want to manage the features for roc_build we have to pipe those features to every package that imports roc_build. Otherwise, one of those locations could pull in roc_build with default features and mess with disabling a specific feature. Is there any way to do a more global feature management? My current work around was to disable all default features for roc_build. This still doesn't fully solve the issue because a crate may enable 1 feature on roc_build and pull that in even when it is disabled in roc_cli.Last updated: Jun 16 2026 at 16:19 UTC