Can you make an emscripten-tagged release?

[svenstaro]

As a downstream packager, the flipping between version that look like this: 90, 91, 92 and 1.31.1 1.31.2, etc is quite a bit of a problem for my packages. Could you please always tag an accompying emscripten-style tag? Or just deprecate emscripten-style tags altogether. Both things work for me but I'd like to stop flipping.

[kripken]

Sorry for the confusion here. I think we can not tag emscripten versions here any more, as that information is captured in the DEPS file in emscripten-releases now.

Unless someone else remembers something I'm forgetting, or someone else uses the emscripten version tags here?

[svenstaro]

I don't really care which way we commit to in the package but I'd just like to stop flip-flopping the version format. So you're saying we can commit to the 90 format?

[kripken]

Yes, exactly. But let's wait a few days though to see if anyone thinks otherwise.

Actually I think I remember @juj found value in the emscripten version tags in this repo, but that was a long time ago. @juj would you object to not doing them any more (which is basically the case now, but inconsistently)?

[sbc100]

I agree that we should probably stick with binaryen-specific versions only.

emscripten now requires a certain binaryen major version as of: See emscripten-core/emscripten#10175.

If you are downstream packager then you probably want to be even more specific about the exact versions you package, which I'm afraid is rather complicated process involving the DEPS file in the emscripten-releases repo and emscripten-releases-tags.txt in the emsdk repo. Therea re some details here: https://github.com/emscripten-core/emscripten/blob/master/docs/process.md.

If you are trying to package emscripten downstream outside of using emsdk then we could really use some help documenting the process and improving it. See emscripten-core/emscripten#10169 for example.

As of now I would not recommend to anyone to use anything but a git clone or emsdk since we don't officially support any other installation method and as you can tell the dependencies for emscripten quite complex. What system are you working on packaging for? Would you be interested in starting a shared document that packagers can use to help the process? (Perhaps packaging.md alongside the existing prcoess.md).

[svenstaro]

This is for Arch Linux. We have the binaryen package here.

I'm afraid I don't have enough time or insight into the emscripten upstream packaging process to make a meaningful contribution.

However, I think such a document would be immensely useful for downstream packagers such as me. So far I've just winged it and it seems to work well.

[sbc100]

Thanks for you efforts so far! If I get time I will start the document. At the very least it would be good have a list of known downstream packagers so we can coordinate with you when we make significant changes.

[svenstaro]

That would be much appreciated. So for the time being, I upgrade binaryen to 90 and hope it kinda works with our emscripten?

[sbc100]

I guess we can close this issue? Or maybe close it once you confirm that version 90 works for you?

[svenstaro]

Yeah, let's close it.

[juj]

Actually I think I remember @juj found value in the emscripten version tags in this repo, but that was a long time ago. @juj would you object to not doing them any more (which is basically the case now, but inconsistently)?

The reason that I tagged Binaryen with matching versions from Emscripten was because that is how the Emscripten installer script looked up which git commit of Binaryen it should build for each tagged release for Emscripten. I.e. when doing a packaged up build of, say, Emscripten 1.35.0, it would look at a matching tag 1.35.0 in all four repos (emscripten, fastcomp, fastcomp-clang, and binaryen). Without matching tags in these repos, the build script would not know which commit of Binaryen it would need to check out for the build for emsdk.

I don't know how Emscripten release builds are now handled, and if such repository matching is needed anymore. But if you guys do not need it for your build&packaging scripts anymore, then it's not needed. (If you are looking to reuse juj/emslave scripts for packaged Emscripten builds like was pondered about at emscripten-core/emscripten#6288 (comment), then you'd need to keep producing the matching tags, as that is how emslave scripts do the correct lookup)

[kripken]

Thanks @juj, yes, we no longer use the tags for the builders (there is a DEPS file in the emscripten-releases repo now). So sounds like we can indeed stop tagging emscripten tags here, and just use the binaryen version_*.