Cargo does not provide a .wasm file in the correct location when building for wasm32-unknown-emscripten

[Herschel]

When building a project with the wasm32-unknown-emscripten target:
cargo build --target=wasm32-unknown-emscripten
a .js file is output in the target/wasm32-unknown-emscripten/debug folder, but not a corresponding .wasm file.

Instead, the .wasm file appears in the target/wasm32-unknown-emscripten/debug/deps folder, named with the metadata suffix.

The expected behavior would be to output both the .js and .wasm in the debug folder. The .js loader file is also trying to load .wasm file from its own folder with the metadata suffix.

If you run rustc --target=wasm32-unknown-emscripten --print=file-names main.rs, you'll see that rustc only prints main.js as an output file, even though emscripten will produce both main.js and main.wasm.

cargo 0.23.0-nightly (8118b02ac 2017-09-14)
rustc 1.22.0-nightly (26015da01 2017-09-23)
x86_64-pc-windows-msvc
emcc 1.37.21

[richard-uk1]

I'm having the same problem. I'd be interested in helping to fix it - but would need to be pointed to the right area of cargo src.

[alexcrichton]

I think this is the same case as #4500 (comment), neither Cargo nor rustc unfortunately knows about this output file.

[richard-uk1]

How would you go about telling rustc/cargo about this file? Would it be better to do it in rustc, or cargo? In cargo, I've found cargo::opt::cargo_rustc::Context::calc_target_filenames, which seems to be one place it could be added.

[alexcrichton]

@derekdreery indeed! So up to this point we've avoided encoding anything target-specific in Cargo, it relies solely on rustc for this sort of information. That being said I think it's time to break that rule! If Cargo were to handle this then I believe yeah, that location is where the fix would go.

[richard-uk1]

Yeah I was worried that I wasn't allowed to do anything target-related, but yes this file doesn't really have anything to do with rustc.

[alexcrichton]

I think ideally rustc would inform Cargo about this as it tends to have more target-specific information, but for the time being I think we can go ahead and implement it in Cargo (in a conservative fashion) and we can move it around later if need be

[richard-uk1]

OK cool.

The situation will change anyway if emscripten comes out of the build chain, and llvm is compiled directly to wasm.

[tatsuya6502]

@Herschel @derekdreery I opened a PR #4570 to address the issue. If you have time, can you please check if it works for you? I do not have environment with emscripten installed.

$ git clone -b target-specific-artifacts https://github.com/tatsuya6502/cargo.git
$ cd cargo
$ cargo build --release

cargo binary will be found in target/release directory.

Thanks!

[richard-uk1]

Cool! Could you submit it as a PR?

[tatsuya6502]

Yes, I submitted it as a PR (#4570). But before it gets merged, I think one of us needs to verify that it actually solves the problem. The PR contains fixes for wasm and Windows DLL (#4500), and I verified the latter. I cannot verify the earlier because I do not have emscripten now.

[Herschel]

Thanks for your work, @tatsuya6502!

The .wasm file now appears in the correct folder. However, the .js file is still trying to load the .wasm file with the incorrect name including the metadata suffix. (for example, web_test-4d1ad28c85a2ee45.wasm instead of web-test.wasm).

See this gist showing the incorrect line in the .js:
https://gist.github.com/Herschel/df22af2b04d69c0ecb6c447a54765d54#file-web-test-js-L1625

Ideally cargo would generate the correct filename in the .js file. You can either:
a) Replace (module_name)-(suffix).wasm with (module-name).wasm in the .js file.
or b) Append var Module = {wasmBinaryFile: "web-test.wasm"}; to the top of the js file.
or c) Maybe there is some way to get emscripten to generate the js with the correct filename?