Gpio cdev feature #29
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ryankurte (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
S-waiting-on-review
|
I know that the doc creation will not work like this. But I have to admit I am lost how to update the doc to be able state there is feature flag. Can someone please point me to the documentation that might help with this? Thank you |
|
Do you mean on docs.rs? You can specify which flags are enabled for the docs.rs rustdoc build - see https://docs.rs/about. If you want to tell the users that a feature flag exists, then I guess you can just put it in the README? |
This feature adds possibility to use newer gpio cdev instead of deprecated gpio sysfs. At the same time maintains backward compatibility as default feature set is still using sysfs.
Right, I have added commit to update the README. Thank you. |
| @@ -11,15 +11,19 @@ | |||
| //! [0]: https://crates.io/keywords/embedded-hal | |||
|
|
|||
| #![deny(missing_docs)] | |||
| #![feature(doc_cfg)] | |||
There was a problem hiding this comment.
is it possible to remove this? i don't think we want to stop building on stable
error[E0554]: `#![feature]` may not be used on the stable release channel
--> src/lib.rs:14:1
|
14 | #![feature(doc_cfg)]
| ^^^^^^^^^^^^^^^^^^^^
There was a problem hiding this comment.
Sure, I am afraid that #[doc(cfg(feature = "gpio_cdev"))] won't work then. So I guess no point in keeping them either. WDYT?
There was a problem hiding this comment.
ahh yeah, that's a bit frustrating, i think building on stable is more important for now. i'd also like to see ci coverage (even though it's only running cargo check).
i guess we could build both in sub-paths (under default-features gates) and choose the default export with a feature, which would put them both in the docs, not require an additional test run, and let people runtime select if required, but, seems more complicated than is probably necessary.
There was a problem hiding this comment.
Ok I have created alternative PR #30 . Let me know which one we should proceed with. Thanks
|
Closing in favour of #30, thanks! |
As requested in #20. This PR adds support for feature that will replace sysfs gpio with cdev gpio.
Default feature set is still the same so it won't broke any existing code.