Repository navigation
build tag wasip2 #142
Description
The current generated bindings use wasip2 as the build tag. This pins the generated bindings to the tinygo compiler targeting wasip2.
Using the wasm component from tiny go with runtime bindings such as wasmtime-go fails because components are not yet supported. Most of the runtimes outside of the rust implementation appear to be implementing wasip1 only and are waiting for wasip2 or components to become more stable.
Removing the build tag is not ideal but does allow for wit bindings to be used in wasip1 runtimes in some cases.
Is there any harm in removing the build tag from the generated bindings?
The goal is to leverage wit-bindgen-go to generate wit definitions but implement a core module vs a component, understanding this is largely dependent on the language/compiler support for wasip1 and wasip2.
Activity
ydnar commentedon Aug 14, 2024
Interesting idea. Do you have a working example?
My guess is you can post-process the files to remove the wasip2 tag and see if it works.
elewis787 commentedon Aug 14, 2024
I should be able to share an example. I'll update here shortly. ( on mobile atm )
I did manually remove the build tag and compiled a wasm module using wasip1 and everything more or less worked.
There are missing functions that have to be added to the guest code or host but the bindings are still useful!
ydnar commentedon Aug 15, 2024
I'd accept a PR with a generator option for tags that default to the current defaults.
elewis787 commentedon Aug 15, 2024
Awesome! I'll put something together and send it your way and add the example.
elewis787 commentedon Aug 16, 2024
work is being done here - https://github.com/elewis787/wasm-tools-go/tree/elewis-build-tag-option-wasip1
tested it locally and have a working example. I am cleaning up the flows and making the WIT/example app public next. I will open up a PR once that is ready.
elewis787 commentedon Aug 23, 2024
Pull request to add the target option is in #145
ydnar commentedon Aug 23, 2024
Upon further reflection, I think we can omit build tags entirely from the generated packages. Can you see if #147 addresses your requirements?
elewis787 commentedon Aug 23, 2024
I like it and it solves my use case! Thank you.
elewis787 commentedon Aug 23, 2024
The only callout that I would make is that having the build tags does help tie the bindings to what the compile targets need to be. Since wasip1 produces a module vs component it was somewhat nice to be forced to target a version.
However, this can be done by the compiler toolchain - so I do agree that the bindings don't need to enforce this.
ydnar commentedon Aug 23, 2024
Module targeting WASI 0.2+ (e.g.
wasm32-wasip2-module) is a work in progress: WebAssembly/component-model#378