feature request: expose tokio vs async-global-executor feature flags

[dignifiedquire]

Looking at rtnetlink it already exposes both the async-global-executor and tokio executors as features, so I think it should be mostly a matter of threading it through.

[mxinden]

I would welcome this change. @dignifiedquire do you want to propose a patch?

[thomaseizinger]

Currently, the linux implementation also hardcodes the use of smol. Would you see changing that in scope @mxinden ?

Disclaimer: I am pretty unfamiliar with this crate and only had a brief look.

[dignifiedquire]

@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.

[dignifiedquire]

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.

[thomaseizinger]

Is this becausertnetlink is only a dependency on Linux and therefore, the feature flag can't target it on other platforms?

[dignifiedquire]

yes, exactly

[thomaseizinger]

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 rtnetlink.

Alternatively, we could make a proxy crate that re-exports everything from rtnetlink that compiles on all platforms but doesn't have any code for MacOS and Windows.

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 rtnetlink to cfg(target) their entire crate under linux.