Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiler-artifact message doesn't include WASM files for --example ... builds #6810

Closed
tangmi opened this issue Apr 1, 2019 · 1 comment · Fixed by #6812
Closed

compiler-artifact message doesn't include WASM files for --example ... builds #6810

tangmi opened this issue Apr 1, 2019 · 1 comment · Fixed by #6812
Labels
C-bug Category: bug

Comments

@tangmi
Copy link

tangmi commented Apr 1, 2019

Problem

Hi all, when I build a binary with --target wasm32-unknown-emscripten, the compiler-artifact message includes the .js and .wasm files under the filenames property. However, when I build an example with --example ..., only the .js file appears in the compiler-artifact message.

cargo-web depends on the compiler-artifacts message to determine which files to serve for its cargo web start command, but it seems no message from cargo provides references to the generated .wasm files for example builds.

Thanks for your time!

Steps

I'm currently experiencing this with the cube example in gfx.

Example output of building cargo build --message-format json --target wasm32-unknown-emscripten --example cube (this output is missing the .wasm file):

{
    "reason": "compiler-artifact",
    "package_id": "gfx_app 0.9.0 (path+file:///E:/external/gfx)",
    "target": {
        "kind": [
            "example"
        ],
        "crate_types": [
            "bin"
        ],
        "name": "cube",
        "src_path": "E:\\external\\gfx\\examples/cube/main.rs",
        "edition": "2015"
    },
    "profile": {
        "opt_level": "0",
        "debuginfo": 2,
        "debug_assertions": true,
        "overflow_checks": true,
        "test": false
    },
    "features": [
        "default"
    ],
    "filenames": [
        "E:\\external\\gfx\\target\\wasm32-unknown-emscripten\\debug\\examples\\cube.js"
        // missing path to: `target\wasm32-unknown-emscripten\debug\examples\cube-9626de08b1305a96.wasm`!
    ],
    "executable": "E:\\external\\gfx\\target\\wasm32-unknown-emscripten\\debug\\examples\\cube.js",
    "fresh": false
}

For comparison, I have copied it to the src directory as cube_example_as_bin and added an entry to the Cargo.toml file:

[[bin]]
name = "cube"
path = "src/cube_example_as_bin/main.rs"

Example output of building cargo build --message-format json --target wasm32-unknown-emscripten (this output includes the .wasm file):

{
    "reason": "compiler-artifact",
    "package_id": "gfx_app 0.9.0 (path+file:///E:/external/gfx)",
    "target": {
        "kind": [
            "bin"
        ],
        "crate_types": [
            "bin"
        ],
        "name": "cube",
        "src_path": "E:\\external\\gfx\\src/cube_example_as_bin/main.rs",
        "edition": "2015"
    },
    "profile": {
        "opt_level": "0",
        "debuginfo": 2,
        "debug_assertions": true,
        "overflow_checks": true,
        "test": false
    },
    "features": [
        "default"
    ],
    "filenames": [
        "E:\\external\\gfx\\target\\wasm32-unknown-emscripten\\debug\\cube.js",
        "E:\\external\\gfx\\target\\wasm32-unknown-emscripten\\debug\\cube.wasm"
    ],
    "executable": "E:\\external\\gfx\\target\\wasm32-unknown-emscripten\\debug\\cube.js",
    "fresh": false
}

Possible Solution(s)

Notes

Output of cargo version: cargo 1.33.0 (f099fe94b 2019-02-12)

@ehuss
Copy link
Contributor

ehuss commented Apr 1, 2019

Oops, looks like a simple fix. I'm going to review the code to see if there are other places where the same mistake was made.

bors added a commit that referenced this issue Apr 2, 2019
Don't include metadata in wasm binary examples.

This removes the metadata hash from wasm example binaries, and consequently also includes the `.wasm` files in the artifact JSON message.

Closes #6810.

I renamed a method and added a new one to maybe make things a little clearer. This cannot be easily tested (see #4973).
@bors bors closed this as completed in #6812 Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants