-
Notifications
You must be signed in to change notification settings - Fork 27
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
feature request: expose tokio vs async-global-executor feature flags #21
Comments
I would welcome this change. @dignifiedquire do you want to propose a patch? |
Currently, the Disclaimer: I am pretty unfamiliar with this crate and only had a brief look. |
@mxinden I can take a look next week probably, if nobody claims it before. @thomaseizinger I would try to avoid smol in this setup and use tokio/async-std directly depending on the current feature. |
I am failing to do this, because this needs to enable features depending on the target, and cargo has not implemented this yet :/ If anyone has ideas, I am all ears. |
Is this because |
yes, exactly |
I wonder if the crate renaming works on the level already? If yes, we could try and make an empty crate with just two features that we can add for those targets and rename it to Alternatively, we could make a proxy crate that re-exports everything from The former would be nice because it is a one-time effort whereas for the latter, we would have to always release a new version, every time they release one. A third idea would be to ask the maintainers of |
I just noticed that with tokio-only rust-libp2p addition of UPD: It pulls the whole |
Looking at
rtnetlink
it already exposes both theasync-global-executor
andtokio
executors as features, so I think it should be mostly a matter of threading it through.The text was updated successfully, but these errors were encountered: