Closed edmellum closed 3 years ago
Hi @edmellum. I've tried building your minimal example, and I agree it doesn't compile. However, it doesn't work for me when I tried to build it using wasm-pack directly either, so I'm not sure if web-bundler is really the problem here.
As far as I can see, the problem is that Bevy, with all of its features enabled, doesn't compile for WebAssembly. Some libraries it depends on, like libloading which isn't compiling in your example, don't really make sense in WebAssembly.
I found this example of building Bevy to WebAssembly: https://github.com/mrk-its/bevy_webgl2_app_template/blob/master/Cargo.toml. Importantly, it includes default-features=false
in its Bevy dependency and then manually turns on different features for the 'web' and 'native' versions.
I'm sorry you're totally right! My minimal example was way too minimal and doesn't match my project at all, the errors didn't even match my project, I don't know what I was thinking. I've updated it now and the errors completely match my project while still compiling with wasm-pack
if cd
ing into the frontend
directory and running wasm-pack build
. A bunch of errors like this from glam
:
error[E0119]: conflicting implementations of trait `std::hash::Hash` for type `f32::vec4_mask::Vec4Mask`:
--> /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/glam-0.11.3/src/f32/vec4_mask.rs:23:64
|
23 | #[derive(Clone, Copy, Default, PartialEq, Eq, Ord, PartialOrd, Hash)]
| ^^^^ conflicting implementation for `f32::vec4_mask::Vec4Mask`
...
65 | impl hash::Hash for Vec4Mask {
| ---------------------------- first implementation here
|
= note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)
I've noticed glam 0.11.3 has a build.rs file that I thought might mess with the target
directory in a hardcoded fashion, but it looks very benign.
Ok! I'm now getting the same result as you. It works with wasm-pack directly, but not with web-bundler :( Interestingly, it also works for me if I set CARGO_TARGET_DIR and run wasm-pack directly.
I think the pieces of the puzzle are:
vec4_sse2
Specifically, it looks like these two conditions are both true, but only one should be allowed to be true at a time:
#[cfg(any(not(target_feature = "sse2"), feature = "scalar-math"))]
#[derive(Clone, Copy, Default, PartialEq, Eq, Ord, PartialOrd, Hash)]
#[cfg(vec4_sse2)]
impl hash::Hash for Vec4Mask {
I've found that this seems to work when you build in release mode! wasm-pack also fails in debug mode, but unlike web-bundler its default is release.
Actually, nevermind that last point. It works in web-bundler if you happened to run it in wasm-pack with that configuration first :facepalm: Similarly, it failed in debug mode with wasm-pack for me because I'd previously run it in debug mode with web-bundler.
I think it's probably something to do with it running that build script with a different target in mind and then caching the result inappropriately.
@edmellum would you mind checking out the bevy-test
branch and see if it works for you?
I found that some of the environment vars that Cargo sets for our backend build.rs script are leaking into the wasm build.rs scripts like Glam's. Specifically CARGO_CFG_TARGET_FEATURE
is leaking through, giving Glam a very strange view on if SSE2 is actually available or not.
My proof of concept is pretty rough. I just unset a few vars before calling wasm-pack. It works for me, but I'd like to confirm it works for you too before cleaning it up to merge into the main branch.
Awesome work! 😃 My app compiles with the bevy-test
branch! It sounds like nested build.rs files makes for some interesting issues and your branch sets the direction for dealing with it in a great way while solving this specific issue. 👏
Thanks @edmellum. I've generalized the fix and cleaned it up a bit, and merged it into the main
branch. I'll be making a 0.1.4 release to crates.io soon with the fix.
Compiling bevy for the web fails, but works using wasm-pack, unless
CARGO_TARGET_DIR
is set to web-target. I've made a minimal example. Seems like something about the target dir causes certain builds to fail, but I haven't been able to figure it out yet.The error messages are a bunch of messages like this: