Closed couchand closed 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?
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 check
ing this project.
Thanks!
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?
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.
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.