emscripten 2.0.10

[carlocab]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

• bump emscripten version
• change llvm revision according to (see formula for details):
  • https://github.com/emscripten-core/emsdk/blob/master/emscripten-releases-tags.txt
  • https://chromium.googlesource.com/emscripten-releases/+/37fc7647c754ac9a28ad588c143b82286de0ef71/DEPS
• use recommended binaryen revision to avoid build failures
  • The same has been done with llvm. See: emscripten: use upstream recommended llvm revision #63183
• update license to reflect bundled llvm and binaryen

[alebcay]

I was holding off on this bump for a while because there was no associated binaryen version bump with it, but frankly, if it works, I'd be okay with crossing my fingers and shipping it.

If emscripten and binaryen end up being so closely coupled (without tagged releases from one or the other), it might make sense to just have binaryen as a resource for emscripten (at the specified commit) while having a binaryen formula as well. The approach irks me a bit (imagine having two copies of binaryen lying around) but the real solution would just be for the respective upstream teams to coordinate releases better, I think.

[carlocab]

Two copies of binaryen? I have two copies of llvm! (Arguably three, because the Xcode toolchain is practically a whole other copy. You can now see why I was so keen on cutting down the bundled llvm.)

Bundling binaryen is perfectly fine though: it's only 35MB.

Though, what I don't understand is: why can't emscripten do their releases based on released versions of their dependencies??

[carlocab]

Nope, this doesn't work. Any chance you know what the problem is, @alebcay? Hopefully, it's just that we're not tracking their preferred version of binaryen...

[alebcay]

I don't really know what the issue is here. I think the error being thrown is from https://github.com/WebAssembly/binaryen/blob/00f96c854ed3691b01fa35bba0a1d010d08958bd/src/tools/wasm-emscripten-finalize.cpp#L312.

[carlocab]

Yep, I agree. Unfortunately, I don't find the error or surrounding code informative about what the problem is...

[carlocab]

I guess there are two possible ways forward with this PR:

1. Bundle emscripten's preferred version of binaryen as a resource.
2. Try emscripten 2.0.8 (it was 2.0.7 before this bump), maybe that plays better with Homebrew binaryen.

The two options are not mutually exclusive, but it would be silly to do them both. Do you have any other ideas or a preference between either of those, @alebcay?

[carlocab]

Decided to go with option 1 for now, though I am happy to change this with feedback.

[carlocab]

I am wondering about the license though.

Since we are packaging emscripten with llvm (and, if this PR works, with binaryen), shouldn't this formula technically also be bound by the licenses of llvm (Apache-2.0 + llvm exceptions) and binaryen (also Apache-2.0)?

[SMillerDev]

Since we are packaging emscripten with llvm (and, if this PR works, with binaryen), shouldn't this formula technically also be bound by the licenses of llvm (Apache-2.0 + llvm exceptions) and binaryen (also Apache-2.0)?

I think it should, yes.

[carlocab]

Ok, cool. Will make that change if the build succeeds.

[carlocab]

10.14 and 10.15 runners don't seem to be working. Best I can tell, everything's been queued since at least three hours ago (see all the newer PRs). Weird.

[carlocab]

Builds on Big Sur. Still queued on Catalina and Mojave. Guess Homebrew binaryen wasn't new enough.

[BrewTestBot]

🤖 A scheduled task has triggered a merge.