search

CosmWasm / wasmvm

Go bindings to the CosmWasm VM
Apache License 2.0
175 stars 102 forks source link

add non-musl linux artifacts to release #399

Closed con5cience closed 1 year ago

con5cience commented 1 year ago

Right now you can pull and use the .so artifacts out of internal/api for use on non-musl Linux platforms.

This change just adds those artifacts to the official release workflow.

webmaster128 commented 1 year ago

Thank you @con5cience. The diff makes sense. However, I wonder for which case you need this. When you install wasmvm as a Go dependency, the shared library is found and linked correctly automatically.

con5cience commented 1 year ago

Thank you @con5cience. The diff makes sense. However, I wonder for which case you need this. When you install wasmvm as a Go dependency, the shared library is found and linked correctly automatically.

This would be a courtesy for installing wasmvm on non-musl systems running pre-compiled Go binaries that may not have been statically linked to the library.

webmaster128 commented 1 year ago

I see, thank you. I would not be fighting against this convenience addition. However, you can already download them by tag from the git tree using the following URLs:

https://raw.githubusercontent.com/CosmWasm/wasmvm/v1.2.1/internal/api/libwasmvm.aarch64.so
https://raw.githubusercontent.com/CosmWasm/wasmvm/v1.2.1/internal/api/libwasmvm.x86_64.so
con5cience commented 1 year ago

I see, thank you. I would not be fighting against this convenience addition. However, you can already download them by tag from the git tree using the following URLs:

https://raw.githubusercontent.com/CosmWasm/wasmvm/v1.2.1/internal/api/libwasmvm.aarch64.so
https://raw.githubusercontent.com/CosmWasm/wasmvm/v1.2.1/internal/api/libwasmvm.x86_64.so

Right, and that's what we've been doing so far, however I'm sure you can understand the risks inherent in that workflow (such as if the repo or tag structure changes). If the artifacts are added to the releases, it reduces fragility and risk to the consumers of the repo, and also makes the UX a bit more professional. :)

webmaster128 commented 1 year ago

I'm buying the consistency argument here. For the risk I'm not convinced. Once in a while URLs change and give you 404 🤷‍♂️. Given that the Go build system hardcodes the path to the library to the gopath folder (the rpath) at build time, I'm also not convinced this is a great flow risk wise.

Anyways, I'll get you the release artifact. Most likely we don't need to rebuild it in the CI because it is already in the checkout and just needs to be uploaded on a tag.

webmaster128 commented 1 year ago

In #415 there is an alternative version of this PR. The main difference is that we don't build the dynamic libs again as they are already in the checkout. Also it adds the .dylib.

webmaster128 commented 1 year ago

They are all in the releases now (implemented via #415). Thank you! https://github.com/CosmWasm/wasmvm/releases/tag/v1.2.2