You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In foyer-rs/foyer#852, we meet a requirement to switch between two tokio implementations: one for production, the other for test.
While it's possible to create one more crate and add two "runtime" feature flags to switch between them, and reduce the interface tweaks works, this approach has several downside:
You must have an extra check mechanism to ensure that exactly one feature flag are selected. ntex-rs has an example, but it's still bothering downstream users to specify a feature correctly. In the case above, we have the knowledge that exactly one tokio impl should be selected and most users would use the default impl.
You have to add a new crate, two feature flags, and propagate the flags among all the consumer subcrates.
I noticed that Cargo has a feature to specify platform specific dependencies with #[cfg(...)] and wonder if it's a solution to switch tokio's impl based on whether cfg(madsim) is on.
However, it seems that this ability is only for targets (or technically, what returns by barely rustc --print=cfg.
Is it possible to support switching implementation based on RUSTFLAGS (cfgs)? Or there is other good workaround for this use case.
In foyer-rs/foyer#852, we meet a requirement to switch between two tokio implementations: one for production, the other for test.
While it's possible to create one more crate and add two "runtime" feature flags to switch between them, and reduce the interface tweaks works, this approach has several downside:
I noticed that Cargo has a feature to specify platform specific dependencies with
#[cfg(...)]
and wonder if it's a solution to switch tokio's impl based on whethercfg(madsim)
is on.However, it seems that this ability is only for targets (or technically, what returns by barely
rustc --print=cfg
.Is it possible to support switching implementation based on RUSTFLAGS (cfgs)? Or there is other good workaround for this use case.
Ref -
#[cfg()]
#1007The text was updated successfully, but these errors were encountered: