WebAssembly!
This PR will enable WebAssembly as a build target. Currently works on macOS, but will be testing on Windows and Linux soon. To test this branch locally, do the following after cloning:
- Run
rake updateto get the latest changes in theassets/Git submodule. - Run
raketo (re)build the gem and install in one command. - Make sure Emscripten tools are available in the current shell (follow these instructions).
- Run
ruby2d build test/wasm.rb --debugto build our little test app. - Run
ruby2d serve build/web/app.htmlto launch the built test app in your default browser.
To conveniently build & serve a file in the test/ directory, you can also use:
rake test:web <name of test>
# i.e. to run `test/wasm.rb`, do...
rake test:web wasm
That's it! If all goes well, should look something like the image below. Let me know how this works, and feedback welcome.
Caveats!
- ~~The build process currently doesn't include media files you might reference in your apps. For example, you can't yet include an image, font, or audio file in your build. This is something we need to figure out.~~ Done!
requiredoesn't work. Because we're using mruby under the hood, there is norequire. I think we should implement our own version ofrequirethat literally inserts the file referenced, kind of like a C#include.- RubyGems do not work. We're using mruby, which doesn't support standard CRuby/MRI gems. Nothing we can really do about that. mruby does have its own gems, but they need to be compiled into the runtime itself (
libmruby.a), can't berequired like standard gems.
great work, excited to test it out!
The mruby is a huge limitation. That's exactly why dragonruby didn't work for me -- I could not figure out how to require gems. Also writing files/sockets/network...
@Nakilon I hear ya. Now that Ruby 3.2 is gaining WASI support, we'll be able to use CRuby in the browser. I haven't tested the preview release yet, but looks promising. Running in a web browser will still impose limitations, regardless of the Ruby engine used, but hopefully will be more feature rich than mruby. Also not sure about how gems will work, but hopefully there's a decent story there too.
Awesome work here, just want to follow up on this stuff as im curious to get some updates on achieving web platform support.
-
Are there any plans to take this PR for mruby across the finish line at some point, its been sitting since March/April
-
Now that Ruby 3.2.0 is released with proper WASM support, maybe its time to start some work towards this. https://github.com/ruby/ruby.wasm contains the official prebuilt binaries.
Hey @westonganger, yea, would be nice to finish this up and merge. (Free time to work on side projects is the enemy here.) Having mruby support is pretty trivial at this point, so we'll probably keep it. And now that Ruby 3.2 is out, and a lot more tooling and documentation exists, would be fun to give that an honest try. I'm not sure of the exact steps to get going, but might start at the Emscripten port, since that's what we're doing today with mruby (and it has all the WASM dependencies ported, like SDL2). If you're interested in doing some experimentation there, happy to open a new PR that's specific to ruby.wasm (separate from mruby). Can also chat about it in the Discord if you like.
@blacktm what remains to be done to merge the mruby stuff?
Also wanted to let you know that the ruby.wasm has made official Ruby 3.2 releases as of today, https://github.com/ruby/ruby.wasm/releases/tag/ruby-3_2-wasm-wasi%2F1.0.1
For Ruby 3.2 web assembly we will need to continue using the emscripten version as SDL2 currently only supports emscripten
Hi @westonganger, I think left for mruby is making sure it works on Windows and Linux/Ubuntu I've only tested on macOS. I also didn't get the virtual file system set up yet. Overall, the developer experience is probably a little rough. This could be merged as a "first draft", then progressively add and test new features.
Good to know that about Ruby 3.2, thanks. I'm down to give that a go, I think would be more popular than an mruby option. Would definitely want to open a new branch after merging this. If you're interested in collaborating on it, feel free to join the #development channel in our Discord. I bet others would be interested on hacking on it also.
Yes if it can be merged as a first draft that would be helpful, we can create issues for any outstanding things such as Window/Linux testing and virtual FS. That would at least give us a baseline to continue forward with. This will allow for mruby development to continue in smaller steps and provide a general sense of direction for implementing cruby wasm support.
Just checking in. Still hoping to see something budge here in regards to the mruby stuff here now.
hi - thanks for referencing my thread on SDL2 / WASM / WASI here. Is anyone in this community interested in collaborating in porting this API from the 'emscripten' target to WASM/WASI to improve more streamlined support for web builds ? This should be of interest to the entire C++ community, and up and coming languages like JAI and Zig My situation is I have a Rust project built around C-FFI foundations (rather than rust community wrappers), this works fine on desktop and the 'emscripten' target, however the rust emscripten compile target has a bug that breaks threading, and will likely never be fixed , because the Rust community focussed on pure WASI bindings. chose my path to hedge my bets between languages, I may need to go back to C++ and am interested in other options, so I vastly prefer to build around C-FFI cross-language low level libs .