`build.rs` doesn't support `wasm` family architecture

[simbleau]

The build.rs script heavily relies on by C++, which is OK (not ideal) but doesn't seem to be configured correctly for the wasm architecture.

If you attempt to build rive-rs for wasm (at least on MacOS M1), you'll end up with this:

cargo build --target wasm32-unknown-unknown

Output:

  cargo:warning=In file included from ../submodules/rive-cpp/include/rive/animation/animation.hpp:3:

  cargo:warning=../submodules/rive-cpp/include/rive/generated/animation/animation_base.hpp:3:10: fatal error: 'string' file not found

  cargo:warning=#include <string>

  cargo:warning=         ^~~~~~~~

  cargo:warning=1 error generated.

I've tried adjusting the .includes in the build.rs but have been fighting uphill battles.

Wondering if there's a priority to support wasm32 or have a pure-rust parser akin to rive-cpp? I would imagine this (web) is the primary supported for rive, so this should probably be considered a bug.

[dragostis]

@simbleau, thank you for reporting. This shouldn't be too hard to fix since we already support wasm.

I'll try to fix this next week. It's likely that we're missing some flags.

[dragostis]

Since we're using C++ stdlib in the C++ runtime, it seems like we'll need to use emscripten to compile the runtime then link it with rive-rs. I might take a crack at this at some point, but I'm currently caught up.

[COCPORN]

Hello! I am in the same situation where I am trying to compile a Bevy app to WASM. Any updates to this?

[dragostis]

Building wasm32-unknown-emscripten instead of wasm32-unknown-unknown works fine, it seems.

Then, linking with other wasm32-unknown-unknown libs should not be a problem.

[simbleau]

I don't think this should be closed @dragostis.

Most rust developers who work with wasm32-unknown-unknown need documentation or guidance to make this work with their existing codebase. Bevy tests on wasm32-unknown-unknown as well, and is their supported target. It's also pretty common for users to use build tools like Trunk which only compile for wasm32-unknown-unknown.

Perhaps this issue should be closed when it's appropriately documented how to run this on web.

[dragostis]

I think plug-and-play compatibility with wasm32-unknown-unknown is at least off the table until we find a solution to compiling the C++ code without Emscripten installed, since rustup won't install it automatically.

This might be possible with something similar to wasm32-unknown-unknown-openbsd-libc, but this one unfortunately only works for C libraries. This cannot work since the C++ code also has a dependency on malloc.

Also, for wasm32-unknown-emscripten we could map wasm32-unknown-unknown -> wasm32-unknown-emscripten automatically in build.rs.

[COCPORN]

This might be a stupid question, but does it really need to be compiled with the Rust toolchain? I thought one of the benefits and goals of WASM was to be able to distribute binaries that had a defined ABI and would run ubiquitously. I would be very happy with prebuilt C++ distributed as part of the Rust-packages as an alternative if that is possible.

Also, I second the comment above. This might well work with Bevy, but at the moment I don't understand how to do it to WASM with Bevy and that is the only target I am currently interested in, so to me, Rive is not an option right now. This could be mitigated with documentation.

[dragostis]

I was under the impression that simply building rive-rs with wasm32-unknown-emscripten should be easily compatible with wasm32-unknown-unknow, but that's not the case. I tried experimenting with this idea, but for a Bevy project what ends up happening is that the link step will be missing libc to link against in the final step.

Building a Bevy project with wasm32-unknown-emscripten also fails because winit only works with wasm32-unknown-unknown.

Re-opening the issue, but I currently don't have any leads/ideas. tree-sitter-c2rust has a solution to this by providing a mini sysroot to build with, but I'm not aware of any such project for C++.

[simbleau]

What's the potential for a Rust-native runtime?
Rust would give you WASM out of the box, and FFI to C++ easily.
These problems seem self-inflicted because C++ doesn't go into Rust and then into WASM easily.

I really hate to be "that guy" but this Bevy runtime is pretty much unusable for anyone who wants to get this on web. :(

[dragostis]

@simbleau, I just pushed to an experimental branch using emscripten's libcxx implementation. Could you please check to see if it works?

[simbleau]

@simbleau, I just pushed to an experimental branch using emscripten's libcxx implementation. Could you please check to see if it works?

Sure, should I get some bandwidth... not today, but soon, hopefully. :)

[dragostis]

Unfortunately, the solution doesn't work because wasm-bindgen's interpreter stumbles when dealing with the C++ part of the generated code. It seems like mixing up non-Rust code is not a way forward for wasm32-unknown-unknown for now.