wg
wg copied to clipboard
[RFC] `svd2rust` workspace generation
As previously discussed at the Rust All-Hands 2019 in Berlin,
this RFC proposes to change the way that svd2rust
generates platform crates,
away from peripheral modules to peripheral sub-crates.
CC (especially) @japaric, @rust-embedded/tools.
At stm32-rs we build svd2rust crates for all STM32 devices, factoring out the common changes to svd files to help reduce duplication of effort. The svd2rust output is turned into a single module per device, and then all devices belonging to the same family are published as part of the family crate. For example, the stm32f405 device is a module in the stm32f4 crate, which is on crates.io. This means there's 11 crates which is already a fair amount to manage -- even with a script publishing them sequentially, it takes some time to publish and then docs.rs takes a real hit each release. In fact we only generate documentation for one or two devices per family to avoid overloading docs.rs.
Overall we have 48 devices so far, and in total over 1500 peripherals, so with this change we'd go from 11 crates to >1500, just for this project. I think it would take it beyond manageable even with automation -- that would be over 6% of all of crates on crates.io!
I totally get wanting to reduce compile times, but for the family projects like stm32-rs I don't think a crate per peripheral is the way to go, if anything I'd like to see built-in support for generating fewer crates. Ideally I'd just have a single stm32-rs crate with every stm32 supported and all the common peripherals automatically factored out!
Perhaps if this is added it could be an optional switch, so at least stm32-rs could keep doing what it does? I like feature-gating the peripherals as a way to reduce compilation times without parallelism and it seems like feature gates would also integrate well with HAL crates providing feature-gated implementations per peripheral. The additive nature of features works perfectly with this approach too.