FR: Add `rust_wasm_library`

UebelAndre commented 3 years ago

There appears to be a desire for something like this which stems from https://github.com/bazelbuild/rules_rust/pull/312

An insightful bit of context can be found in https://github.com/bazelbuild/rules_rust/pull/240#discussion_r337676010 but essentially, it seems to be rust_binary is 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 https://github.com/bazelbuild/rules_rust/issues/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.

PiotrSikora commented 3 years ago

See my previous comments:

We maintain a custom wasm_rust_binary target in Envoy with automatic transitions to Wasm/WASI targets: https://github.com/envoyproxy/envoy/blob/f91f79b7a58c9b429a23b2882f67128071fcf495/bazel/wasm/wasm.bzl

And Emscripten did something similar with wasm_cc_binary: https://github.com/emscripten-core/emsdk/tree/eaa49511f401c18fc3b87ef644524936540977d7/bazel#using-wasm_cc_binary

But this should really be supported directly in rules_rust.

UebelAndre commented 3 years ago

@PiotrSikora Could you reiterate why the rust_library target 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 of out_binary?

PiotrSikora commented 3 years ago

@PiotrSikora Could you reiterate why the rust_library target 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 of out_binary?

Bazel won't even build library with .wasm extension, see this https://github.com/bazelbuild/rules_rust/pull/626#issuecomment-793582479.

UebelAndre commented 3 years ago

Bazel won't even build library with .wasm extension, 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 .dll

If 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 why wasm targets should be *_binary targets? That's the bit that's not necessarily clear to me. To me *_binary means you'd expect to pass the file to some thing else as an executable but is that true of all .wasm files?

roman-kashitsyn commented 2 years ago

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.

bazelbuild / rules_rust

FR: Add `rust_wasm_library` #771