Skip to content
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

Attach lib dependencies to release tags #36

Open
codefromthecrypt opened this issue Feb 9, 2023 · 4 comments
Open

Attach lib dependencies to release tags #36

codefromthecrypt opened this issue Feb 9, 2023 · 4 comments

Comments

@codefromthecrypt
Copy link

Right now, installing shared libraries is a manual task, and they are quite large (dozens of megabytes). I've been told that the shared libraries are only 1.7MB, which would be a refreshing change, but also it would be better to have these attached to the release tags. That way end users can get the trusted libs per-platform similar to how they can get them in wasmer-go and wasmedge-go. Wanna give this a go?

ex.
bytecodealliance/wasmtime-go@df14d9f
https://github.com/bytecodealliance/wasmtime-go/blob/7d1d102e5213c4ba7b15e41907322b27533b3999/includebuild.go

@hydai
Copy link
Member

hydai commented Feb 9, 2023

Thanks for the suggestion. It sounds good for making users get wasmedge-go easily.

@q82419 maybe we can have these artifacts in the 0.12.0 release.

We have two kinds of users:

  1. Need to compile the wasm to leverage ahead of time compiler on their environments. (this will need llvm inside which needs more storage)
  2. Only need to execute the wasm applications whether in pure wasm or universal wasm formats. (lightweight one. <2 MB).

@codefromthecrypt
Copy link
Author

ps I'm not sure what the terms mean (pure wasm/universal wasm) but I would highly suggest having WASI work with whatever the lib attachments are. We have a comparison test in wazero for example, which uses wasmtime, wasmer and wasmedge go libraries. if the attached libs didn't work with wasi, it would not work for us and we'd still have to manually install. ack that our comparison tests aren't really that important but in any case I think users will expect WASI to work, which I've no idea if is the case in "pure wasm" or "universal wasm"

@hydai
Copy link
Member

hydai commented Feb 9, 2023

Pure wasm -> A wasm/wasi application.
Universal wasm -> Pure wasm + a custom section that contains native binary which is compiled and created by our compiler.
That's just a term from the WasmEdge side. You can assume the libraries provide an execution engine for WASM+WASI.

@q82419
Copy link
Member

q82419 commented Mar 30, 2023

I think this may be considered in v0.13.0 releases in the future.
The timeline of v0.12.0 is too nearly, and we should consider the platforms of extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants