Build more runtimes targeting PolkaVM #3209
Merged
+25
−7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michalkucharczyk
approved these changes
Feb 6, 2024
davxy
approved these changes
Feb 6, 2024
andresilva
approved these changes
Feb 6, 2024
Yes, I'm planning to rename a bunch of stuff in a future refactoring PR. |
bgallois
pushed a commit
to duniter/duniter-polkadot-sdk
that referenced
this pull request
Mar 25, 2024
This PR improves compatibility with RISC-V and PolkaVM, allowing more runtimes to successfully compile. In particular, it makes the following changes: - The `sp-mmr-primitives` and `sp-consensus-beefy` crates unconditionally required an `std`-only dependency; now they only require those dependencies when the `std` feature is actually enabled. (Our RISC-V target is, unlike WASM, a true `no_std` target where you can't accidentally use stuff from `std` anymore.) - One of our dependencies (the `bitvec` trace) uses a crate called `radium` which doesn't compile under RISC-V due to incomplete autodetection logic in their `build.rs` file. The good news is that this is already fixed in the newest upstream version of `radium`, and the newest version of `bitvec` uses it. The bad news is that the newest version of `bitvec` is not currently released on crates.io, so we can't use it. I've [created an issue](ferrilab/ferrilab#5) asking for a new release, but in the meantime I forked the currently used `radium` 0.7, [fixed the faulty logic](paritytech/radium-0.7-fork@ed66c8a) and used cargo's patching capabilities to use it for the RISC-V runtime builds. This might be a little hacky, but it is the least intrusive way to fix the problem, doesn't affect WASM builds at all, and we can trivially remove it once a new `bitvec` is released. - The new runtimes are added to the CI to make sure their compilation doesn't break.
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR improves compatibility with RISC-V and PolkaVM, allowing more runtimes to successfully compile.
In particular, it makes the following changes:
sp-mmr-primitivesandsp-consensus-beefycrates unconditionally required anstd-only dependency; now they only require those dependencies when thestdfeature is actually enabled. (Our RISC-V target is, unlike WASM, a trueno_stdtarget where you can't accidentally use stuff fromstdanymore.)bitvectrace) uses a crate calledradiumwhich doesn't compile under RISC-V due to incomplete autodetection logic in theirbuild.rsfile. The good news is that this is already fixed in the newest upstream version ofradium, and the newest version ofbitvecuses it. The bad news is that the newest version ofbitvecis not currently released on crates.io, so we can't use it. I've created an issue asking for a new release, but in the meantime I forked the currently usedradium0.7, fixed the faulty logic and used cargo's patching capabilities to use it for the RISC-V runtime builds. This might be a little hacky, but it is the least intrusive way to fix the problem, doesn't affect WASM builds at all, and we can trivially remove it once a newbitvecis released.