build tag wasip2

[elewis787]

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.

[ydnar]

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]

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]

I'd accept a PR with a generator option for tags that default to the current defaults.

[elewis787]

Awesome! I'll put something together and send it your way and add the example.

[elewis787]

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]

Pull request to add the target option is in #145

[ydnar]

Upon further reflection, I think we can omit build tags entirely from the generated packages. Can you see if #147 addresses your requirements?

[elewis787]

I like it and it solves my use case! Thank you.

[elewis787]

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]

Module targeting WASI 0.2+ (e.g. wasm32-wasip2-module) is a work in progress: WebAssembly/component-model#378