See the next section for details.
-
Add to
dependencies:[dependencies] # ... anysc-rustls = { version = "0.1", optional = true }
-
Activate one of
io_*feature flags: -
Depending on the use case, enable some inheritied features:
aws-lc-rsaws_lc_rsearly-datafipsloggingringtls12
-
Write your code with
anysc-rustlsas with{tokio, futures}-rustls.
Just reexporting all the items of one of
based on the io_* feature flag selected.
The point is that this is a crate: it enables, for some (maybe niche) crates that
- support multiple async runtimes over different async IO interfaces
(
tokio::io,futures::io) - AND optionally provide rustls-powered TLS functionality
behind a feature flag (like
tls)
, to switch {async crate}-rustls dependencies without any needless dependencies.
That's impossible by other way: if simply having a submodule reexporting
tokio-rustls and futures-rustls conditionally with respective feature flags (like tokio-io, futures-io),
indeed it works, but the crate's [dependencies] will be like
[dependencies]
tokio-rustls = { optional = true, version = ... }
futures-rustls = { optional = true, version = ... }
[features]
tokio-io = ...
futures-io = ...
tls = ...Here, how we setup the features?
-
tokio-io = if "tls" ["dep:tokio-rustls"]+futures-io = if "tls" ["dep:futures-tls"]impossible.
-
tls = if "tokio-io" ["dep:tokio-rustls"] else if "futures-io" ["dep:futures-tls"]impossible.
-
tls = ["dep:tokio-rustls", "dep:futures-rustls"]works, but one of them must be needless.
So it's impossible to avoid undesired dependencies in this way.
However, it's enabled by a crate-level shim layer as this crate:
[dependencies]
anysc-rustls = { version = "0.1", optional = true }
[features]
tls = ["dep:anysc-rustls"]
tokio-io = ["anysc-rustls?/io_tokio", ...]
futures-io = ["anysc-rustls?/io_futures", ...]Yes, that's done by the <crate>?/<feature> syntax!