wasm-pack breaks dependencies that use code generation

[jsheard]

🐛 Bug description

When wasm-pack build compiles a dependency that uses build.rs to generate code, rustc fails to find the generated code and errors out.

    Updating crates.io index
   Compiling num-traits v0.2.6
   Compiling cgmath v0.16.1
   Compiling approx v0.1.1
   Compiling rand v0.4.3
   Compiling num-traits v0.1.43
error: couldn't read \\?\C:\code\wasmtest\target\wasm32-unknown-unknown\release\build\cgmath-bd1cefcc88d97b09\out/swizzle_operator_macro.rs: The filename, directory name, or volume label syntax is incorrect. (os error 123)
   --> C:\Users\Josh\.cargo\registry\src\github.com-1ecc6299db9ec823\cgmath-0.16.1\src\macros.rs:480:1
    |
480 | include!(concat!(env!("OUT_DIR"), "/swizzle_operator_macro.rs"));
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

👟 Steps to reproduce

1. Create a standard wasm-pack project.
2. Add cgmath = "0.16" or nalgebra = "0.16" to [dependencies]
3. Build with wasm-pack build

Running cargo build then wasm-pack build succeeds, but wasm-pack can't do a fresh build.

🌍 Your environment

Include the relevant details of your environment.
wasm-pack version: 0.5.1
rustc version: 1.31.0
platform: Windows 10

[drager]

I'm unable to reproduce this on a Linux x64 system, so this might be a issue only for Windows.

[mocsy]

I'm experiencing something similar own windows as well.

 [4/9] Compiling to WASM...
...
   Compiling markup5ever v0.7.5
error: couldn't read \\?\C:\testproj\target\release\build\cssparser-03cc3f627f1fb3f1\out/tokenizer.rs: The filename, directory name, or volume label syntax is incorrect. (os error 123)
   --> C:\Users\x\.cargo\registry\src\github.com-1ecc6299db9ec823\cssparser-0.24.1\src\lib.rs:116:5
    |
116 |     include!(concat!(env!("OUT_DIR"), "/tokenizer.rs"));
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `cssparser`.
warning: build failed, waiting for other jobs to finish...
error: build failed

The same project compiles fine with cargo build --target wasm32-unknown-unknown on Windows, fails on my linux with some rust-lld issue.
cargo build works on both platforms.

There seem to be two bugs:
Why does wasm-pack fail on include! on windows?
and
Why does wasm-pack try to process my [build-dependencies] and build.rs to wasm?
In my case markup5ever is not in [dependencies] of my project, instead, it's a dependency of a [build-dependencies] of my build.rs. I don't want my build.rs wasmified nor published to npm.

@jsheard's case seems to be the same, the code generator package is being wasmified along with the project.

[danwilhelm]

This issue seems to be resolved in v0.6.0 by #389 (in fact, the include! issue was partly discussed in the PR). I reproduced the issue above in Windows on v0.5.1. Starting fresh, it worked correctly on v0.6.0.

---

@mocsy

Why does wasm-pack fail on include! on windows?

In wasm-pack v0.5.1, env!("OUT_DIR") was canonicalized. On Windows, this converts the path into a so-called "extended-name path" beginning with \\?\, as seen in the error. The concat! very unfortunately hard-codes a _forward_ slash to this. However, Windows paths use _backward_ slashes. Normally this doesn't matter, but:

"File I/O functions in the Windows API convert / to \ as part of converting the name to an NT-style name, except when using the \\?\ prefix." - Microsoft docs

This inflexibility with extended-name paths and forward slashes caused the errors seen in this issue.

In wasm-pack version 0.6.0, env!("OUT_DIR") is no longer canonicalized, so by default it is left as ".", for better or worse. Since it is now a regular path, Windows correctly auto-converts the appended / to \.

---

Why does wasm-pack try to process my [build-dependencies] and build.rs to wasm?

When wasm-pack says Compiling to WASM..., it is actually running cargo build --lib --target wasm32-unknown-unknown. So, it is both processing the build script and compiling the main code to WebAssembly.

Compiling markup5ever v0.7.5 is cargo's output, not wasm-pack's. So, cargo is likely compiling markup5ever for your build script, not into WebAssembly. It would be interesting to test your build script's target by displaying the TARGET env var when your build script is run.

I do see your point that the message Compiling to WASM... was confusing here and could be more accurate. @ashleygwilliams?

[jsheard]

Yep, this is fixed in 0.6.0. Thanks!