We want to update the ruby.wasm project so it can use bindings generated from their WAPM package instead of their manually building ruby.wasm and wrapping it.
This requires:
[x] Figuring out ruby.wasm's build process
[x] Find the ruby.wasm file which implements rb-abi-guest.wit
[x] Update wapm.toml to also expose the library and bindings
[x] Update the corresponding build-package.sh to put binaries in the right place
[ ] Publish to wapm.dev under the wasmer organisation (or maybe Michael-F-Bryan for now?)
[ ] Update the JavaScript package to use the wapm.dev package instead of their version
[ ] Make a PR upstream
Building
You can start up their development environment by running the following command from the repository's root directory:
(note: this means all files and folders created during the build process will be owned by root on your host machine, but we can't use the --user $(id -u) trick because it breaks npm later on)
Full build instructions are available here, but you can use that Docker environment to compile from source. On my computer, this takes 5-15 minutes.
Hopefully you won't need to call scripts manually, but the code that actually compiles ruby.wasm (the library, not the executable) and copies it to the ruby-wasm-wasi package's dist/ directory is here, however it only gets invoked from ruby-head-wasm-wasi's build script :shrug:
Architecture
Their packaging system seems a bit convoluted because they've got a "template" JavaScript package under packages/npm-packages/ruby-wasm-wasi/ which contains the actual bindings and a "HEAD" package (ruby-head-wasm-wasi) which seems to just re-export code from the template.
The API being exported can be found in rb-abi-guest.wit, while the functionality imported by the host is defined in rb-js-abi-host.wit. They've also created a hand-written wrapper which manages the library instantiation and makes calling library functions slightly easier.
The executables that have already been uploaded to WAPM are under packages/wapm-packages/ and just provide access to the ruby and irb commands.
We want to update the ruby.wasm project so it can use bindings generated from their WAPM package instead of their manually building
ruby.wasm
and wrapping it.This requires:
ruby.wasm
's build processruby.wasm
file which implementsrb-abi-guest.wit
wapm.toml
to also expose the library and bindingsbuild-package.sh
to put binaries in the right placewasmer
organisation (or maybeMichael-F-Bryan
for now?)Building
You can start up their development environment by running the following command from the repository's root directory:
(note: this means all files and folders created during the build process will be owned by root on your host machine, but we can't use the
--user $(id -u)
trick because it breaksnpm
later on)Full build instructions are available here, but you can use that Docker environment to compile from source. On my computer, this takes 5-15 minutes.
Hopefully you won't need to call scripts manually, but the code that actually compiles
ruby.wasm
(the library, not the executable) and copies it to theruby-wasm-wasi
package'sdist/
directory is here, however it only gets invoked fromruby-head-wasm-wasi
's build script :shrug:Architecture
Their packaging system seems a bit convoluted because they've got a "template" JavaScript package under
packages/npm-packages/ruby-wasm-wasi/
which contains the actual bindings and a "HEAD" package (ruby-head-wasm-wasi
) which seems to just re-export code from the template.The API being exported can be found in rb-abi-guest.wit, while the functionality imported by the host is defined in rb-js-abi-host.wit. They've also created a hand-written wrapper which manages the library instantiation and makes calling library functions slightly easier.
The executables that have already been uploaded to WAPM are under
packages/wapm-packages/
and just provide access to theruby
andirb
commands.