-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplified conditional compilation #138
Conversation
use crate::windows_native::utils::PeakIterExt; | ||
use super::typedefs::{Caps, LinkCollectionNode}; | ||
use super::types::{ItemNodeType, Items, MainItemNode, MainItems}; | ||
use super::super::error::{WinError, WinResult}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not really a fan of relative paths for imports, when its necessary to go up multiple levels.
Its much clearer with one glance from where the item was imported with the absolute path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made this change to keep the backend more self-contained and not depend on the name it was imported under. My original idea was to do something like this:
#[cfg_attr(feature = "linux-native", path = "linux_native.rs")]
#[cfg_attr(feature = "windows-native", path = "windows_native/mod.rs")]
mod platform;
Which obviously broke those imports.
After changing my approach to cfg_if
I decided to nevertheless keep it. I can revert the paths if you want.
use windows_native::HidApiBackend; | ||
cfg_if! { | ||
if #[cfg(all(feature = "linux-native", target_os = "linux"))] { | ||
//#[cfg_attr(docsrs, doc(cfg(all(feature = "linux-native", target_os = "linux"))))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why comment out these cfg_attrs, and not the ones below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The attribute is used to document that a certain function is limited to certain configurations:
The native backends should not appear to the public api and therefore the attribute seemed pretty useless. However I just commented them out for now to make it easier to reenable them in case I am wrong and they did actually serve a purpose that I missed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think you are right. We can just remove them completely, since its backend code.
My last concern was, that cfg_if completely breaks IDE support. Apparently its now limited to only being able to index one of multiple cfg_if branches, which should be good enough. |
I recently fount out that this crate currently fails to compile on non-windows platforms when the
windows-native
feature is active. This is caused by a missingtarget_os = "windows"
in one of the#[cfg(...)]
attributes.I refactored the individual
#[cfg(...)]
attributes to use thecfg_if
macro instead to improve readablillity and hopefully prevent such mistakes in the future.