-
Notifications
You must be signed in to change notification settings - Fork 128
Support building for Wasm/WASI #624
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Just to feel things out: would you by any chance be open at all to building wasm artifacts (potentially without Intl)? Absolutely fine and understandable if not, in which case we'd probably do so in a mirror over in the It's possible that we'll have to keep an additional set of patches anyway, in which case this would be moot, but I hope to be able to get rid of those before too long. |
|
This is certainly interesting, there was some push for this from wasmer a while back: wasmerio#2, but it was much more complicated IIRC. This PR is actually pretty minimal, so that's nice. The only thing missing for me is missing CI. What do others think? cc @jdm @mrobinson |
|
I wasn't sure whether you'd want to spend CI time on this—see also my previous question. But I'm happy to add a configuration for that for sure. |
This commit changes the `build.rs` and `makefile.cargo` files to support compiling mozjs for `wasm32-wasip1` and `wasm32-wasip2`. SpiderMonkey itself has long supported targeting WASI, but the build system requires some finagling to line everything up just right for these targets. It also frobs things a little bit to make tests pass (disabling the one test that uses threads and thus isn't supported at all on wasm32-wasi right now.) Signed-off-by: Till Schneidereit <[email protected]>
Signed-off-by: Till Schneidereit <[email protected]>
|
I added CI, which is passing, so this should be ready, I think. |
Signed-off-by: Till Schneidereit <[email protected]>
Apparently Rust 1.85 needs more `cfg` than the newer version I tested with. Signed-off-by: Till Schneidereit <[email protected]>
Signed-off-by: Till Schneidereit <[email protected]>
Signed-off-by: Till Schneidereit <[email protected]>
Signed-off-by: Till Schneidereit <[email protected]>
sagudev
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - comment
Signed-off-by: sagudev <[email protected]>
Signed-off-by: sagudev <[email protected]>
|
As a side note: I see that the aarch64 based macOS builders are way faster than the Linux builders. I don't think there'd be any issue with running the WASI builds on macOS machines, and would be happy to make that change if desired. It'd probably not decrease end-to-end times though, so might not matter all that much. |
This might be due to sccache (linux env changes more frequently then mac, thus invalidating caches). |
|
Given that I wrote last two commits we need someone else to review those. |
This commit changes the
build.rsandmakefile.cargofiles to support compiling mozjs forwasm32-wasip1andwasm32-wasip2. SpiderMonkey itself has long supported targeting WASI, but the build system requires some finagling to line everything up just right for these targets.It also frobs things a little bit to make tests pass (disabling the one test that uses threads and thus isn't supported at all on wasm32-wasi right now, and making
criterionnot userayon.)Eventually it'd be nice to also do build artifacts as for other platforms, but for now that's not a blocker.
Note that this currently only works with the Intl disabled using #623, because
diplomat-runtimeunfortunately assumes thatwasm32as a target arch implies the availability of web APIs. With that applied and building without default features, this passes acargo test --target=wasm32-wasip1run.