Add Rust bindings for the runtime and the SpiderMonkey engines #103
Conversation
|
Note that this is a draft for now, because there's some build system wrangling still required to make it not just Work On My Machine™️, because documentation is entirely absent, and because after the latest SpiderMonkey upgrade things don't entirely work: compilation and linking work just fine, but the componentization step fails with the message |
This commit includes updates of various tools used for building and testing StarlingMonkey: - Binaryen - Corrosion CMake Cargo integration - wasm-tools - Wasmtime - Wizer No changes in behavior should occur as a result of these updates.
…mpiling multiple crates to static libs and trying to link all of them into the final binary This also replaces linking SpiderMonkey's Rust static library with including the required crates into our own library, achieving an end result of having a single static Rust library to link.
... and use that wherever we previously stored a pointer to the `Engine` in a static global. Signed-off-by: Till Schneidereit <[email protected]>
|
Hey @tschneidereit would you mind if I try to revive this PR? :) |
|
@andreiltd please do! |
Signed-off-by: Till Schneidereit <[email protected]>
|
Indeed, please do! I just pushed a couple more commits here, one of which I had lying around and that might be helpful, and the other containing documentation of the authorship situation of the Rust bindings. The latter is crucial for landing any of this. One thing to note is that because of some issues with the bindings generation, the bindings will sometimes be wrong in subtle ways. There's not a huge amount we can do about that, but it might be useful to at least document somehow. |
This PR introduces rust-bindgen generated bindings for the StarlingMonkey runtime itself, as well as generated bindings and higher-level abstractions building on those for the SpiderMonkey engine.
The latter are derived from the Servo project's mozjs crate and share much of the code. The build system is substantially overhauled though to enable direct use of the Bytecode Alliance's fork of the repository containing SpiderMonkey, instead of having to update tarball based source code drops.
To ensure compliance with mozjs's license and easy code movement between files, all Rust code in the core runtime is licensed under the MPL2 instead of the Bytecode Alliance's default Apache 2.0 with LLVM exceptions. At the board meeting on 2024-07-25, the BA's board approved a license exception to permit use of the MPL2 for part or all of the StarlingMonkey project, as required by our IP policy.