Enable Serde for no-std targets #896
Conversation
Before this patch, Serde still depended on std, and the `use-serde` feature of this crate would not compile for pure no-std targets.
| @@ -27,7 +27,7 @@ secp-recovery = ["secp256k1/recovery"] | |||
| # Instead no-std enables additional features required for this crate to be usable without std. | |||
| # As a result, both can be enabled without conflict. | |||
| std = ["secp256k1/std", "bitcoin_hashes/std", "bech32/std"] | |||
| no-std = ["hashbrown", "core2/alloc", "bitcoin_hashes/alloc", "secp256k1/alloc"] | |||
| no-std = ["hashbrown", "core2/alloc", "bitcoin_hashes/alloc", "secp256k1/alloc", "serde/alloc"] | |||
There was a problem hiding this comment.
This doesn't work because serde is optional but now no-std enables it.
There was a problem hiding this comment.
Oof, good catch. This is extremely misleading syntax on the part of the cargo folks. I stupidly read this as a conditional feature enabling, even though we've had endless discussions about that being impossible..
| @@ -41,7 +41,7 @@ core2 = { version = "0.3.0", optional = true, default-features = false } | |||
|
|
|||
| base64-compat = { version = "1.0.0", optional = true } | |||
| bitcoinconsensus = { version = "0.19.0-3", optional = true } | |||
| serde = { version = "1", features = [ "derive" ], optional = true } | |||
| serde = { version = "1", default-features = false, features = [ "derive" ], optional = true } | |||
There was a problem hiding this comment.
With this change, users of std and use-serde no longer get serde/std. I don't know a solution to this problem, conditionally enabling features.
|
Ah, good points. This highlights a limitation of feature selection in Rust. Thanks for the quick feedback. I'll go ahead and close this PR, as its clearly not the solution I thought it was 🤦 I am working on an embedded project (cortex m7), and I would like to use the "official" rust-bitcoin, without forking it if possible. I'll think a bit more to see if there is another way around this hurdle. |
|
One work around is to depend on Also, |
|
Ah, great suggestion. Seems obvious in retrospect! Thanks 🍻 |
|
@tcharding, unfortunately your suggestion was not possible, because cargo requires sub-crate features to be re-exported, before a dependent crate can access them. I've opened an issue to discuss further: #904 |
|
I explained further on the issue :) |
Before this patch, Serde still depended on std, and the
use-serdefeature of this crate would not compile for pure no-std targets.