Rahix / avr-device

Register access crate for AVR microcontrollers
Apache License 2.0
171 stars 66 forks source link

Add shared feature for just the common bits #44

Closed couchand closed 4 years ago

couchand commented 4 years ago

I'm writing some code that could be shared across AVR chips, and I'd like to depend on the common parts of this repo. The downstream users will be pulling it in anyway, but I'll leave it to them to pick a chip.

This feature allows a dependent crate to opt in to not picking a specific device, keeping the current user-friendly behavior of a compile fail when a device isn't chosen.

Happy to discuss more or bikeshed the feature name.

Rahix commented 4 years ago

Can you explain a bit more what this is needed for? I think adding such a feature-flag just nullifies the error-mechanism altogether because as soon as any crate in the dependency tree enables it, no error will be emitted regardless of whether any chips were selected. Note that you can still have libraries depend on avr-device, for example avr-hal-generic pulls in avr-device without any chip-feature enabled. That's ok, it just means that any crate intending to use the libaray must select a chip-feature for avr-device and avr-hal-generic can only really use the non-specific parts of avr-device.

But maybe you have something I'm missing here?

couchand commented 4 years ago

Oh my you're right. I was satisfied that it wouldn't cause problems for other users of this crate, but hadn't considered that it would eliminate the aid for anything downstream of my code.

I came to this because I reflexively constantly run cargo check, and so it bothers me a bit that the crate won't build on its own. But I do have unit tests (which select a chip feature), so all I need to do is get in the habit of going straight to cargo test rather than ever checking this project.

Thanks!

Rahix commented 4 years ago

Maybe we can make the hard error a warning instead so you can still build, but get a notice that you might have missed something?

couchand commented 4 years ago

Well, I'd rather it be a hard error for everyone and maybe a minor habit break for me in one specific case than weaken what otherwise seems to be a reasonable protection into a warning that can easily get lost in the noise.