Skip to content
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

Merged
merged 5 commits into from
Jan 25, 2024
Merged

Conversation

sidit77
Copy link
Contributor

@sidit77 sidit77 commented Jan 10, 2024

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 missing target_os = "windows" in one of the #[cfg(...)] attributes.

I refactored the individual #[cfg(...)] attributes to use the cfg_if macro instead to improve readablillity and hopefully prevent such mistakes in the future.

use crate::windows_native::utils::PeakIterExt;
use super::typedefs::{Caps, LinkCollectionNode};
use super::types::{ItemNodeType, Items, MainItemNode, MainItems};
use super::super::error::{WinError, WinResult};
Copy link
Owner

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.

Copy link
Contributor Author

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"))))]
Copy link
Owner

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?

Copy link
Contributor Author

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:
image

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.

Copy link
Owner

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.

@ruabmbua
Copy link
Owner

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.

@ruabmbua ruabmbua merged commit e33a939 into ruabmbua:master Jan 25, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants