hawkw
commented
4 months ago Ah, yup, that's annoying, sorry about that!
I think both of your proposed solutions make sense and should fix the problem. I went with the approach of just generating the pins for an individual task when I wrote this code initially because it seemed conceptually cleaner, but I think changing this to just always generate all the pins for every task would be simpler and avoid triggering rebuilds. On the other hand, we would probably want to generate submodules for each individual task if we went with that approach, because otherwise, we could potentially have namespace collisions (although in practice I don't see any cases where pin names might collide...)
The separate crate approach feels nicer IMO, since it means that every task doesn't see every pin, and it lets us avoid doing the codegen at all when building tasks that don't depend on GPIO IRQs. I'll look into that, and if it turns out to be annoying, I might just do the "always generate all pins" approach instead.
I recently noticed that a no-op rebuild (
cargo xtask dist ...) is doing a bunch of work.The culprit appears to be anything with a dependency on
drv-stm32xx-sys-api:This takes ~20 seconds; if all of the tasks were 0.2s (a typical no-op rebuild speed), it would be closer to 5.5 seconds.
I believe this is because the
stm32xx-sysbuild now depends ontask_name, so it can't be cached between tasks.Possible fixes:
gpio_irq_pins.rs, instead only the ones associated with a particular taskgpio_irq_pins.rscodegen to a separate crate, so only tasks that actually use it will have to be rebuilt (gimlet-seqandstm32h7-sprot-server)