-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementing a wasmer backend for wiggle #2949
Comments
Based on the source of |
I'm not familiar with how In addition to Wasmtime has nearly subsumed Lucet in our (Fastly) production use. Once we have EOL'd Lucet, we intend to refactor wiggle to specialize it to just work with Wasmtime. Having wiggle factored to support two different runtimes makes it harder to read & write, among other design compromises we've been forced into. So, wiggle may end up evolving so that it is not viable to use on a different engine. Additionally, there is ongoing work to evolve the witx language and define the first ABI for Interface Types (WebAssembly/WASI#422, WebAssembly/interface-types#132), and we'll be evolving wiggle to support those developments as well. |
I'm going to close this since wiggle is unsable enough that we're not going to be adding this to this repository. The wiggle infrastructure is not slated to suvive indefinitely as it's intended to be supplanted with wit-bindgen in the future as well. |
We are currently using
wasmer
as a WebAssembly runtime and I'd like to simplify the way host functions are done by using WITX as an interface definition language and generating guest/host bindings withwiggle
.Is there a list of things I would need to do in order to implement a
wasmer-wiggle
crate? Or could you point me to a list of resources I can use as a starting point?The text was updated successfully, but these errors were encountered: