Export a working synth_compile rule and bundle meld/synth as hermetic toolchains

[avrabe]

Thanks for rules_wasm_component — the hermetic wasm toolchain bundles are great to build on. While wiring jess (a hardware-integration project that builds falcon firmware: wasm component → meld fuse → synth → Cortex-M ELF → Renode), I hit two gaps that block expressing the firmware build hermetically. Filing together since they're the same "downstream firmware build" story.

1. synth_compile isn't usable

relay/BUILD.bazel loads synth_compile from @rules_wasm_component//wasm:defs.bzl but the call is disabled with:

"Temporarily disabled: synth_compile rule now requires a synth attribute that this file doesn't provide."

So there's no working path to compile a fused core module to a Cortex-M ELF via the rules.

2. meld/synth aren't bundled as hermetic toolchains

meld_fuse lives in @meld//rules:meld.bzl, and synth is @synth//crates:synth. To use them a consumer must bazel_dep on meld and synth — which drags their rules_verus / rules_rocq_rust / rules_lean (Nix) proof toolchains into a firmware-only build. A firmware consumer shouldn't need the proof toolchains.

Impact

jess can hermetically wasm_validate + wasm_optimize the falcon component today, but cannot express meld_fuse → synth_compile → renode_test without either (a) an unimplemented rule or (b) pulling in the full verification stack. For now we fall back to the prebuilt CLIs in a shell script.

Suggested direction

• Finish/export synth_compile with a synth toolchain attribute (analogous to how the wasm bundle registers wasm-tools), so synth_compile(wasm_module=…, target="cortex-m4f") works standalone.
• Provide meld/synth as hermetic toolchains from rules_wasm_component (or thin rules_meld/rules_synth) that fetch prebuilt binaries, so a firmware build doesn't depend on the proof toolchains.

Happy to test against the falcon component (relay falcon-flight-v1.27.wasm) once there's something to try. Thanks!

[avrabe]

Small follow-up while integrating from jess: to consume a prebuilt/released component (relay's falcon-flight.wasm) I needed a WasmComponentInfo, and there's no adopt/import rule, so I wrote a tiny local shim that works for wasm_validate:

load("@rules_wasm_component//providers:providers.bzl", "WasmComponentInfo")
def _impl(ctx):
    f = ctx.file.wasm
    return [DefaultInfo(files = depset([f])),
            WasmComponentInfo(wasm_file = f, wit_info = None, component_type = "component",
                              imports = [], exports = [], metadata = {}, profile = "release",
                              profile_variants = {})]
adopt_wasm_component = rule(implementation = _impl,
    attrs = {"wasm": attr.label(allow_single_file = [".wasm"], mandatory = True)})

Would a first-class wasm_component_import / adopt rule (deriving wit_info/imports/exports from the component where possible) be welcome upstream? Happy to contribute it. (wasm_optimize on such an adopted component hits a separate input-staging bug — filed as #490.) Thanks!

[avrabe]

Gentle nudge from the jess loop — still relevant, and the offer stands. The concrete need is unchanged: consuming a prebuilt/released component (relay's falcon-flight.wasm) currently requires the local adopt_wasm_component shim above just to get a WasmComponentInfo, and the firmware chain (synth_compile toolchains) still can't be expressed without dragging meld/synth's proof toolchains in.

Happy to send a PR for a first-class wasm_component_import / adopt rule (deriving wit_info/imports/exports where possible) if that direction is welcome — just confirm you'd take it and I'll open it. No rush; flagging so it doesn't go stale.