Automatically build and release upon push of a new tag. #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is motivated by the fact that Emscripten does not guarantee ABI compatibility across its versions. (See comments here; I recall seeing a statement of non-compatibility in the docs, but can't find it anymore.) This implies that HDF5 compiled with one version of emscripten may not work with libraries compiled with another version; we've been fortunate so far, but may not be so lucky in the future. I've already started observing link failures when trying to migrate my application to 64-bit Wasm.
This PR adds an action that allows the h5wasm maintainer to easily build and publish tarballs with a new version of emscripten. Simply create and push a tag of the structure
vXXX_YYY
whereXXX
is some arbitrary name that does not contain underscores, andYYY
is the desired version of Emscripten. This will then automatically do a build and create a release like https://github.com/LTLA/libhdf5-wasm/releases/tag/v0.2.0-test_3.1.8. So, if anyone requests a new set of builds, you can easily just push a tag, walk away, and let the CI handle the rest.(Well, almost. 1.10.8 fails with Emscripten 3.1.25 because its clang is more strict about some bad C code. In that case, one could just create a new branch, remove 1_10_8 from the Makefile, and then push a new tag on that branch.)