2022-09-07 23:32:08 +00:00
|
|
|
[workspace]
|
2024-02-15 03:35:29 +00:00
|
|
|
members = ["bitcoin", "hashes", "internals", "fuzz", "io", "units", "base58"]
|
2023-11-14 22:14:56 +00:00
|
|
|
resolver = "2"
|
2023-03-22 02:15:30 +00:00
|
|
|
|
2024-02-15 03:35:29 +00:00
|
|
|
[patch.crates-io.base58check]
|
|
|
|
path = "base58"
|
|
|
|
|
2023-03-22 02:15:30 +00:00
|
|
|
[patch.crates-io.bitcoin]
|
|
|
|
path = "bitcoin"
|
2022-12-15 19:52:07 +00:00
|
|
|
|
|
|
|
[patch.crates-io.bitcoin_hashes]
|
|
|
|
path = "hashes"
|
2023-06-27 22:57:25 +00:00
|
|
|
|
|
|
|
[patch.crates-io.bitcoin-internals]
|
|
|
|
path = "internals"
|
Add a `bitcoin_io` crate
In order to support standard (de)serialization of structs, the
`rust-bitcoin` ecosystem uses the standard `std::io::{Read,Write}`
traits. This works great for environments with `std`, however sadly
the `std::io` module has not yet been added to the `core` crate.
Thus, in `no-std`, the `rust-bitcoin` ecosystem has historically
used the `core2` crate to provide copies of the `std::io` module
without any major dependencies. Sadly, its one dependency,
`memchr`, recently broke our MSRV.
Worse, because we didn't want to take on any excess dependencies
for `std` builds, `rust-bitcoin` has had to have
mutually-exclusive `std` and `no-std` builds. This breaks general
assumptions about how features work in Rust, causing substantial
pain for applications far downstream of `rust-bitcoin` crates.
Here, we add a new `bitcoin_io` crate, making it an unconditional
dependency and using its `io` module in the in-repository crates
in place of `std::io` and `core2::io`. As it is not substantial
additional code, the `hashes` io implementations are no longer
feature-gated.
This doesn't actually accomplish anything on its own, only adding
the new crate which still depends on `core2`.
2023-10-04 05:51:26 +00:00
|
|
|
|
|
|
|
[patch.crates-io.bitcoin-io]
|
|
|
|
path = "io"
|
2023-08-08 08:47:05 +00:00
|
|
|
|
|
|
|
[patch.crates-io.bitcoin-units]
|
|
|
|
path = "units"
|