build and publish a wasi binary on release

[codefromthecrypt]

If wabt was compiled for a wasi target, any wasi runtime can run it which provides flexibility both for ad-hoc CLI use (broader than the binaries on the release page) as well embedded use (without dynamic libraries)

For example, wazero could use this to keep dev dependencies light for wat based tests and also spec tests. Right now, we need an offline installation step and shell forking to use wat2wasm

[keithw]

Not crazy -- we already build with emscripten in CI, so it doesn't seem that far-fetched to include the resulting artifact in the GitHub release. Do you feel up to submitting a PR to adjust the release workflow?

[raphamorim]

Does this issue is still relevant @keithw ? If yes, I can add the build with emscripten in the GH release. Would be worth to have it as GH package (https://github.com/features/packages)?

[sbc100]

But why should this happen upstream in the wabt repo? Why can't anyone who wants to, simply compile wabt for whatever system they choose?

For example, why can't wazero already compile and use wabt?

I'm not against building wabt binaries for various architecture, just curious why it can't happen downstream?

[raphamorim]

I'm not against building wabt binaries for various architecture, just curious why it can't happen downstream?

mhmm, I think is a valid point @sbc100, since will be adding the scope of package releasing wabt for different platforms.

[codefromthecrypt]

TL;DR; I think a wasm binary on the releases page or a package makes a lot of sense. It is on-brand for being in a WebAssembly org, as well, IMHO.

wazero made a decision to not repeat the effort of wat2wasm, and so some users are having to get it on their own and compile if the released binaries doesn't match, or for embedded use.

While wazero could make a tracking repo and match release-for-release, it would seem pointing people to the project and having wasi being a valid platform, just like Darwin is both on-brand for a WebAssembly project and in service of users asking for issues like this.

If you prefer to close this because it is an anti-goal or any other reason it is your choice of course.

[codefromthecrypt]

what might not be obvious about the question for a package (not that I'm requesting this specifically as it isn't precisely what I'm looking for), is that if in container format, this allows docker integration to work with it similar to https://github.com/vmware-labs/webassembly-language-runtimes.

Basically wasm is really empowering, and it is convenient for users to be able to get wasm from a normal release page vs try to find who is tracking it, if anyone and get it from their releases...

[sbc100]

We had a propsal to add wasi package back in #1068. At the time we decided not to move forward, but perhaps we should revisit.

[keithw]

I agree that it would be nice if there was a healthy ecosystem of downstream distributors packaging WABT with (reproducible, attributed-to-a-Git-commit!) builds for various architectures and constituencies, including wasm32-wasi alongside Debian x86, etc.

But if GitHub is how today's cool kids want to get their binaries, it seems like a small change to take our existing emscripten build (which we already do for the CI workflow) and include the same stanzas in the release workflow. So if somebody submits a PR... I'd be in favor of revisiting. This feels a lot simpler/smaller than #1068.