Cumulative develop branch update #73
Conversation
* Fix styling * Run cargo fmt * Bump core version to 0.2.2-dev * More version bumps
…text (#48) * Documents feature flags in README and add support for lazy-static-context * Fix lazy static context feature flag * Add compile error * Bump version to 0.6.0-dev * More all -> any feature flag fixes * Fix clippy feature flags
* Fixed benches to use new parse functions * Fixed building for no_std
* Release v0.6.0 * Fix version dep * Fix top-level package version dep
* Fix no_std builds attempt 2 - Turn off default features for core in gen and genmult - Use serde-json-core (no_std support) in dev-dependencies Relates to #71 * Use resolver="2" Allows us to use serde_json in dev-dependencies and compile for no_std: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver * revert unnecessary changes
| #[cfg(all(feature = "static-context", feature = "lazy-static-context"))] | ||
| compile_error!("Should only enable one of static-context or lazy-static-context"); |
There was a problem hiding this comment.
Can't we get away with this? Making features non-additive makes life hard for downstream as it can lead to incompatible dependency trees. Maybe just automatically assume lazy static when static-context isn't set.
There was a problem hiding this comment.
Those two feature flags are never meant to be used together. If that happens, the combination is meaningless and it's a config error of the packages using it.
There was a problem hiding this comment.
The thing is that this "meaningless" combination isn't the fault of any packages using this crate. Imagine this dependency graph ( X -> Y means X depends on Y):
A -> B
A -> C
B -> libsecp256k1(static_context)
C -> libsecp256k1(lazy_static_context)
The way that feature unification works in cargo is that a single version of libsecp256k1 is included in the dependency tree with both features enabled. It isn't the fault of A that its dependency use incompatible features.
There was a problem hiding this comment.
I see. We need to choose which overwrites which though. I'll take a look (mostly whether lazy_static works good enough on no_std) to resolve this.
There was a problem hiding this comment.
Looks like an easy decision -- static_context doesn't have additional dependencies, while lazy_static_context introduces lazy_static. So let's make lazy_static_context overwrites static_context.
|
(Now merge-able!) |
No description provided.