Repository navigation
FR: Add rust_wasm_library #771
Description
Activity
See my previous comments:
- Add support for wasm-bindgen. #240 (comment)
- Add support for wasm-bindgen. #240 (comment)
- add flag to allow putting out binary whenever #312 (comment)
- Re-add support for building Wasm libraries as executables. #626 (comment)
We maintain a custom
wasm_rust_binarytarget in Envoy with automatic transitions to Wasm/WASI targets:
https://github.com/envoyproxy/envoy/blob/f91f79b7a58c9b429a23b2882f67128071fcf495/bazel/wasm/wasm.bzlAnd Emscripten did something similar with
wasm_cc_binary:
https://github.com/emscripten-core/emsdk/tree/eaa49511f401c18fc3b87ef644524936540977d7/bazel#using-wasm_cc_binaryBut this should really be supported directly in
rules_rust.@PiotrSikora Could you reiterate why the
rust_librarytarget needs to return an executable? It seems like you should be able to grab the file from CrateInfo::output. Could that be used in place ofout_binary?@PiotrSikora Could you reiterate why the
rust_librarytarget needs to return an executable? It seems like you should be able to grab the file from CrateInfo::output. Could that be used in place ofout_binary?Bazel won't even build library with
.wasmextension, see this #626 (comment).Bazel won't even build library with
.wasmextension, see this #626 (comment).Sounds like you're referring to this?
Traceback (most recent call last): File ".../rules_rust/rust/private/rust.bzl", line 179, column 32, in _rust_shared_library_impl return _rust_library_common(ctx, "cdylib") File ".../rules_rust/rust/private/rust.bzl", line 221, column 32, in _rust_library_common return rustc_compile_action( File ".../rules_rust/rust/private/rustc.bzl", line 614, column 29, in rustc_compile_action return establish_cc_info(ctx, crate_info, toolchain, cc_toolchain, feature_configuration) + [ File ".../rules_rust/rust/private/rustc.bzl", line 671, column 59, in establish_cc_info library_to_link = cc_common.create_library_to_link( Error in create_library_to_link: 'libhello_world-665202032.wasm' does not have any of the allowed extensions .so, .dylib or .dllIf so I feel like that's part of the work that would need to be done to create some
rust_wasm_*rules. But is this the basis for whywasmtargets should be*_binarytargets? That's the bit that's not necessarily clear to me. To me*_binarymeans you'd expect to pass the file to some thing else as an executable but is that true of all.wasmfiles?I'd love to see this implemented as well.
My use-case: I want to build a Wasm module and pass it as input into a test that instantiates the Wasm module.
With no clear design I'm gonna close this out. In case folks still need wasm binaries, there's some prior-art for this in
rules_rust_wasm_bindgen
rules_rust/extensions/wasm_bindgen/private/wasm_bindgen.bzl
Lines 163 to 180 in af24d27
There appears to be a desire for something like this which stems from #312
An insightful bit of context can be found in #240 (comment) but essentially, it seems to be
rust_binaryis being used in some (now) wasm edge cases but instead, we should probably have a more first class rule for supporting these cases?I came across this while trying to understand #604 which at first glance just seems to be a quick solution to unblock a larger set of functionality but could ultimately stand to be re-reviewed.