Better no-std support#894
Conversation
| [features] | ||
| default = ["std", "miniscript"] | ||
| std = [] | ||
| std = ["bitcoin/std", "miniscript/std"] |
There was a problem hiding this comment.
❌ I don't think we need miniscript/std for anything. This will unnecessarily add miniscript as a dependency if someone enables the std feature.
| default = ["std", "miniscript"] | ||
| std = [] | ||
| std = ["bitcoin/std", "miniscript/std"] | ||
| no-std = ["hashbrown", "bitcoin/no-std", "miniscript/no-std"] |
There was a problem hiding this comment.
Why does rust bitcoin and rust miniscript make no-std a feature :S
I am looking at the source of rust miniscript and rust bitcoin and it looks like the no-std feature doesn't do anyhing (absence of std makes it no_std)`
Let's not add this feature if this is the case.
There was a problem hiding this comment.
Since there's no way to enable the no-std dependencies due to the absence of std I don't see another way. But maybe we could add these only to the crates/bdk project, and just document what dependencies need to be manually added for anyone using the bdk_chain in a no std project other than with bdk?
There was a problem hiding this comment.
Since there's no way to enable the
no-stddependencies due to the absence ofstdI don't see another way.
Ok so I see that hashbrown needs to be enabled to have HashMap. I think what we do in bdk_chain is the right way to solve this specific problem: Use BTreeMap instead unless hashbrown feature is enabled which makes it faster by using an actual hashbrown hashmap. If that's too offensive then just make hashbrown a mandatory dependency. That seems way less harmful than this feature flag.
I think adding this feature just to enable features in another crate is not a good solution:
- Crates depending on
bdkwill have to do the same thing and so theno-stdthing spreads everywhere. - It means
--all-featuresenablingstdandno-stdwhich just seems awful.
I think just telling people that they have to manually depend on bitcoin and or miniscript and enable their no-std feature manually is probably the right way to go for now. I hope we can remove no-std upstream.
There was a problem hiding this comment.
Ok, I'm on-board with not adding a no-std feature and just documenting what needs to be manually enabled by downstream projects who are building for that environment. I think no-std is going to be uncommon/advance user thing anyway and certainly a lower support priority relative to the rest of the 1.0.0 changes going on. I'll add an issue to document how to use bdk in a no std environment and then this PR can be just the changes for std and bumping esplora-client, how does that sound?
There was a problem hiding this comment.
@tcharding gave us some good advice:
we can just always enable the no-std feature and optionally enable std.
[edit] this solves the problem for rust-bitcoin only. I wonder if we can do the same thing for rust-miniscript too.
There was a problem hiding this comment.
I had a quick look and I rekon it should work for miniscript also.
|
@notmandatory Do you want to take over this ticket? I think you are allowed to directly push to my branch. |
|
A good explanation of how to verify your crate works with I'm expanding the scope of this a bit tackle #920 also. |
|
I ran into a couple issues with getting
|
|
BTW, I'm testing % cargo build -p bdk_chain --no-default-features --features bitcoin/no-std,hashbrown --target thumbv6m-none-eabi |
In case its useful, as of |
|
@tcharding so my understanding is that In any case we need to |
|
Correct. We used Script/ScriptBuf to mimic types in the stdlib (Path/PathBuf), out of interest do types exist named as you suggest Foo/FooSlice? |
| @@ -13,7 +13,7 @@ readme = "README.md" | |||
|
|
|||
| [dependencies] | |||
| bdk_chain = { path = "../chain", version = "0.3.1", features = ["serde", "miniscript"] } | |||
There was a problem hiding this comment.
You need default features off on bdk_chain here too
|
Not sure if this is from an issue on master or not but seems to break if you do I get this error |
ece4a21 to
72b5f96
Compare
|
I'm stumped too. I get the same error as above ( But the same build command with I don't understand why the |
Probably they use a refcell when they don't have access to |
Ok, you are 100% right, in |
|
cc @sanket1729 in case he wants to chime in. |
544e013 to
82cc5db
Compare
|
I have a work-around for the |
|
I think |
|
Looks like this will eventually need to add I have this in a branch here if you want: benthecarman@d7459e9 |
|
Should esplora-client be bumped to v0.5.0? |
|
Per discord conversation added this to alpha.1 milestone. @evanlinjin would you rather we get this in before or after #976? I can take it over if it needs any rebasing. |
- Use `default-features = false` for `miniscript`,`bitcoin`,and `bdk_chain` - Introduce `bdk_chain/std` feature - Add GitHub workflow `check-no-std` (not yet completly working) - Update GitHub workflow `check-wasm` to disable default `std` features
82cc5db to
7ab84be
Compare
esplora-client to 0.4|
I've rebased this PR and removed from the commit message and PR description the part about updating the |

This replaces #893
Description
Carrying over relevant maintenance changes from release 0.27.2 to bdk
master.default-features = falseforminiscriptandbitcoinstdfeatures forbdk,bdk_chainandbdk_esploraNotes to the reviewers
The
default-features = falseforbitcoinandminiscriptis to letbdkbe unbiased for things like no-std.Changelog notice
stdfeatures forbdk,bdk_chainandbdk_esploraChecklists
All Submissions:
cargo fmtandcargo clippybefore committing