SpiderMonkey CMake package: use alternate artifacts if specified. #90
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
cfallin
added a commit
to cfallin/StarlingMonkey
that referenced
this pull request
Jul 27, 2024
This depends on a bunch of pending PRs: - Stacked on top of bytecodealliance#89 and bytecodealliance#90 - Pulls in spidermonkey-wasi-embedding artifacts from bytecodealliance/spidermonkey-wasi-embedding#18 (hash updated, but use local checkout variant from bytecodealliance#90 to test before that merges) When built with: ``` $ mkdir build/; cd build/ $ cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF -DWEVAL=ON $ make ``` This PR will result in a `starling.wasm`, a prebuilt compilation cache of ICs in `starling-ics.wevalcache` (~1.8MiB), and a `componentize.sh` that takes a `--aot` option. I haven't yet quite worked out how to successfully use componentize.sh, so I can't claim this is end-to-end tested yet, but it is invoking weval successfully and ICs are wevaled at least.
There was a problem hiding this comment.
I would somewhat prefer using an env var for this instead of hard-coding a specific path to check. Would you mind looking at how the WPT harness does this and seeing if that kind of setup works for you?
And if it does work, please also update the README to document this.
When developing StarlingMonkey using an existing SpiderMonkey build with no SM changes, it is very convenient to download and use pre-built artifacts for SM from the CI on `spidermonkey-wasi-embedding`, and we do not want to lose this convenience or approachability. However, when modifying SpiderMonkey itself, it is nearly impossible to do development with the current setup: the debug loop requires merging changes to `gecko-dev` with one PR, updating the hash in `spidermonkey-wasi-embedding` with another PR, getting both merged and waiting for the build in CI before StarlingMonkey can use the new engine. Rather than require a local hack for such cases, this modifies the SpiderMonkey CMake module to recognize a `SPIDERMONKEY_BINARIES` environment variable, and use artifacts there instead. This allows the developer to point this to a local clone of `spidermonkey-wasi-embedding` with a modified `gecko-dev`, rebuilt with `rebuild.sh` as needed. The `README` is updated with details on how to use this.
cfallin
force-pushed
the
allow-local-spidermonkey
branch
from
adacf75
to
d52ef04
Compare
cfallin
changed the title
|
Sure thing, updated! This now takes a (cc @guybedford I think from #81: this check that Till linked above is checking |
cfallin
added a commit
to cfallin/StarlingMonkey
that referenced
this pull request
Jul 29, 2024
This depends on a bunch of pending PRs: - Stacked on top of bytecodealliance#89 and bytecodealliance#90 - Pulls in spidermonkey-wasi-embedding artifacts from bytecodealliance/spidermonkey-wasi-embedding#18 (hash updated, but use local checkout variant from bytecodealliance#90 to test before that merges) When built with: ``` $ mkdir build/; cd build/ $ cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF -DWEVAL=ON $ make ``` This PR will result in a `starling.wasm`, a prebuilt compilation cache of ICs in `starling-ics.wevalcache` (~1.8MiB), and a `componentize.sh` that takes a `--aot` option. I haven't yet quite worked out how to successfully use componentize.sh, so I can't claim this is end-to-end tested yet, but it is invoking weval successfully and ICs are wevaled at least.
cfallin
added a commit
to cfallin/StarlingMonkey
that referenced
this pull request
Jul 29, 2024
(Stacked on top of bytecodealliance#90.) When built with: ``` $ mkdir build/; cd build/ $ cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF -DWEVAL=ON $ make ``` This PR will result in a `starling.wasm`, a prebuilt compilation cache of ICs in `starling-ics.wevalcache` (~1.8MiB), and a `componentize.sh` that takes a `--aot` option. I haven't yet quite worked out how to successfully use componentize.sh, so I can't claim this is end-to-end tested yet, but it is invoking weval successfully and ICs are wevaled at least.
guybedford
approved these changes
Jul 29, 2024
cfallin
added a commit
to cfallin/StarlingMonkey
that referenced
this pull request
Jul 29, 2024
(Stacked on top of bytecodealliance#90.) When built with: ``` $ mkdir build/; cd build/ $ cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF -DWEVAL=ON $ make ``` This PR will result in a `starling.wasm`, a prebuilt compilation cache of ICs in `starling-ics.wevalcache` (~1.8MiB), and a `componentize.sh` that takes a `--aot` option. I haven't yet quite worked out how to successfully use componentize.sh, so I can't claim this is end-to-end tested yet, but it is invoking weval successfully and ICs are wevaled at least.
cfallin
added a commit
to cfallin/StarlingMonkey
that referenced
this pull request
Jul 29, 2024
(Stacked on top of bytecodealliance#90.) When built with: ``` $ mkdir build/; cd build/ $ cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_WASM_OPT=OFF -DWEVAL=ON $ make ``` This PR will result in a `starling.wasm`, a prebuilt compilation cache of ICs in `starling-ics.wevalcache` (~1.8MiB), and a `componentize.sh` that takes a `--aot` option. I haven't yet quite worked out how to successfully use componentize.sh, so I can't claim this is end-to-end tested yet, but it is invoking weval successfully and ICs are wevaled at least.
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.
When developing StarlingMonkey using an existing SpiderMonkey build with no SM changes, it is very convenient to download and use pre-built artifacts for SM from the CI on
spidermonkey-wasi-embedding, and we do not want to lose this convenience or approachability.However, when modifying SpiderMonkey itself, it is nearly impossible to do development with the current setup: the debug loop requires merging changes to
gecko-devwith one PR, updating the hash inspidermonkey-wasi-embeddingwith another PR, getting both merged and waiting for the build in CI before StarlingMonkey can use the new engine.Rather than require a local hack for such cases, this modifies the SpiderMonkey CMake module to recognize a
SPIDERMONKEY_BINARIESenvironment variable, and use artifacts there instead. This allows the developer to point this to a local clone ofspidermonkey-wasi-embeddingwith a modifiedgecko-dev, rebuilt withrebuild.shas needed. TheREADMEis updated with details on how to use this.