panoptix-za / web-bundler

Bundles a Rust WebAssembly frontend application for publishing
Apache License 2.0
11 stars 3 forks source link

Can't compile bevy #5

Closed edmellum closed 3 years ago

edmellum commented 3 years ago

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:

  error[E0433]: failed to resolve: use of undeclared crate or module `imp`
    --> /Users/username/.cargo/registry/src/github.com-1ecc6299db9ec823/libloading-0.6.7/src/lib.rs:66:20
     |
  66 | pub struct Library(imp::Library);
     |                    ^^^ use of undeclared crate or module `imp`
JWorthe commented 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.

edmellum commented 3 years ago

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 cding 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)
edmellum commented 3 years ago

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.

JWorthe commented 3 years ago

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:

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 {
JWorthe commented 3 years ago

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.

JWorthe commented 3 years ago

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.

JWorthe commented 3 years ago

@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.

edmellum commented 3 years ago

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. 👏

JWorthe commented 3 years ago

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.