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

Switch implementation based on RUSTFLAGS? #15140

Open
tisonkun opened this issue Feb 4, 2025 · 1 comment
Open

Switch implementation based on RUSTFLAGS? #15140

tisonkun opened this issue Feb 4, 2025 · 1 comment

Comments

@tisonkun
Copy link

tisonkun commented Feb 4, 2025

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:

  1. 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.
  2. 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.

Ref -

@weihanglo
Copy link
Member

You're probably looking for something like https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618, or #15125

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

No branches or pull requests

2 participants