feat(wasm-builder): New approach to build demos#3602
Conversation
|
plz check this #3588 (comment) btw |
| @@ -0,0 +1,21 @@ | |||
| // This file is part of Gear. | |||
| // | |||
| // Copyright (C) 2023 Gear Technologies Inc. | |||
There was a problem hiding this comment.
I suggest removing the year number from the copyright since it is not consistent across the source code and we will not update it later
There was a problem hiding this comment.
I see most of files have year when just a few don't
|
|
||
| //! Module for memory pages. | ||
|
|
||
| #![allow(clippy::assertions_on_constants)] |
There was a problem hiding this comment.
merge master and remove this
| @@ -0,0 +1 @@ | |||
|
|
|||
There was a problem hiding this comment.
why examples/signal-wait/** is empty?
| gear-stack-buffer = { path = "stack-buffer" } | ||
| gear-utils = { path = "utils/utils" } | ||
| gear-wasm-builder = { path = "utils/wasm-builder", default-features = false } | ||
| wasm-dep-builder = { path = "utils/wasm-dep-builder" } |
There was a problem hiding this comment.
Do we want to prefix it with gear as for the others?
| [dependencies] | ||
| gcore.workspace = true | ||
| parity-scale-codec.workspace = true | ||
| gstd = { workspace = true } |
There was a problem hiding this comment.
| gstd = { workspace = true } | |
| gstd.workspace = true |
|
|
||
| [dependencies] |
|
|
||
| # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html |
|
|
||
| # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html |
| gmeta = { workspace = true } | ||
| gstd = { workspace = true, features = ["debug"] } | ||
| demo-wat.workspace = true | ||
| gclient-binaries = { path = "binaries" } |
There was a problem hiding this comment.
Would it be better to call it demo-binaries?
|
|
||
| [dev-dependencies] | ||
| gsdk = { path = ".", features = ["testing"] } | ||
| gsdk-binaries = { path = "binaries" } |
| demo-ping.workspace = true | ||
| demo-futures-unordered.workspace = true | ||
| demo-meta-io.workspace = true | ||
| gtest-binaries = { path = "binaries" } |
| prometheus-endpoint.workspace = true | ||
|
|
||
| [dev-dependencies] | ||
| gear-authorship-binaries = { path = "binaries" } |
| repository.workspace = true | ||
|
|
||
| [dependencies] | ||
| cargo_metadata = "0.18.1" |
There was a problem hiding this comment.
Do you want to move them into the workspace deps?
|
|
|
Can you describe the approach in the PR outline? |
|
Can we maybe put "dependency builder" inside gear-wasm-builder itself? |
It will replace gear_wasm_builder some day, so is there any reason to merge them now? Just for notice: as it was mentioned, there are a few problems with these approach, and as far as we discussed with @ark0f they're already solved, but not pushed |
Done |
|
Temporary closing in favour of opened referencing issue as won't be implemented |
This is a new approach to build Gear programs which can replace
gear-wasm-builder.Schematic architecture:

Pipeline:

Purpose of program build script is just write features to lock file and don't use any
cargo:rerun-ifinstructions so default cargo heuristics are enabled.Binaries crate build script list its build dependencies and corresponding reads lock files to obtain program features then it runs
cargo build -p program1 -p program2socargobuilds WASM binaries effectively and concurrently. Then it writes to lock files to skipcargoinvocation in next or in another binaries crate to avoid few seconds cache verificationPros:
Features are tracked automatically so we don't need to re-run build script each time like in
gear-wasm-builder(can be mitigated bycargo-metadataandCargo.tomltracking)gear-wasm-builderbuilds program via newcargocommand in the same target directory so eachcargoprocess blocks other.wasm-dep-buildercollects list of programs so only onecargoprocess runs.Cons:
It is important to create binaries create that will list and build programs
Current problem:

When crate includes itself as dev dependency (any integration tests) with different feature set then cargo build and runs 2 different versions of build script - for workspace and for tests.
gear-wasm-buildercase is thatcargobuilds and runs script just once with merged feature set.So, how to resolve these features? Should we deliver different WASM binaries? Or just merge feature sets?
I vote for merging but we need some mechanism to obtain all of feature sets cargo resolved for each build script invocation of program before build script invocation of binaries crate if we don't want to waste time on WASM build with incomplete feature set