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

Adding #[wasm_bindgen] means you can't run cargo bench anymore #114

Closed
fitzgen opened this issue Apr 9, 2018 · 2 comments
Closed

Adding #[wasm_bindgen] means you can't run cargo bench anymore #114

fitzgen opened this issue Apr 9, 2018 · 2 comments

Comments

@fitzgen
Copy link
Member

fitzgen commented Apr 9, 2018

You get link errors and things like that.

Ideally, we should make all the wasm-bindgen generated code guarded by #[cfg(target_arch = wasm32)] or something like that.

The

[lib]
crate-type = ["cdylib"]

stuff is a little harder. It can be commented out just when running cargo bench, but that is clunky. Ideally that would not be necessary either.

@alexcrichton
Copy link
Contributor

One idea would be to use binaries as the output target rather than cdylib, and wasm-bindgen could presumably perform wasm-gc and keep the binaries small (and strip the main function or something like that)

That would still require you to separate code, however, into a binary and a library as only the library would be available for writing benchmarks and tests.

Overall I think the situation isn't great and this is somewhat of a Cargo issue. Ideally you'd be able to customize the crate-type more aggressively than only by what's written in the Cargo.toml.


I wonder, though, perhaps the project template for wasm could have two crates? One crate, the primary one, is an rlib which is benchmark-able and testable (and using wasm-bindgen). The other, a cdylib, is purely a reexport of the public contents of the rlib (aka pub use other_crate::*). I believe that should still produce a working wasm target and would be relatively low overhead? (maybe a pain to remember to build a different target for wasm, but scripts may be able to automate this)

@alexcrichton
Copy link
Contributor

cc rust-lang/cargo#5367

alexcrichton added a commit that referenced this issue Apr 27, 2018
Currently `#[wasm_bindgen]` generates a bunch of references to symbols that
don't actually exist on non-wasm targets, making it more difficult to get a
crate working across multiple platforms. This commit updates the symbol
references to be dummy ones that panic on non-wasm targets to allow simple
testing/benchmarking to work on native targets.

While this isn't a perfect solution for #114 it's probably as good as we can do
for now pending upstream Cargo features, so I'm gonna say that it...

Closes #114
alexcrichton added a commit that referenced this issue Apr 27, 2018
Currently `#[wasm_bindgen]` generates a bunch of references to symbols that
don't actually exist on non-wasm targets, making it more difficult to get a
crate working across multiple platforms. This commit updates the symbol
references to be dummy ones that panic on non-wasm targets to allow simple
testing/benchmarking to work on native targets.

While this isn't a perfect solution for #114 it's probably as good as we can do
for now pending upstream Cargo features, so I'm gonna say that it...

Closes #114
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants