Build ARM64 MacOS releases #4397

dschuff · 2021-12-16T00:53:24Z

This allows them to run on both Intel and ARM hardware.

dschuff · 2021-12-16T00:54:19Z

Addresses #4334
The other option is to build two different packages (reduces the overall size but means you have to care which one you get).

d3lm · 2021-12-16T20:18:29Z

This is amazing! Thanks so much for creating this PR 🙌

dschuff · 2021-12-16T22:50:03Z

Hm, maybe don't thank me until it actually works 🤣
would it be more useful to have a single package with a universal binary, or separate package?
@kripken and Binaryen folks, do you have opinions on whether it would be better to do universal binaries or separate packages? Do we know anything about who all uses these packages?

kripken · 2021-12-16T23:04:18Z

@dschuff

do you have opinions on whether it would be better to do universal binaries or separate packages? Do we know anything about who all uses these packages?

I think wasm-pack is the biggest user of these packages that I'm aware of. ccing @ashleygwilliams @drager

dschuff · 2021-12-16T23:31:55Z

Also: how much do we trust the mac SDK and our ability to avoid accidentally writing ARM-incompatible code? Enough to keep the CI build single-arch (since the ARM version can't be tested anyway) and avoid taking 2x the time to compile on the mac builder?

d3lm · 2021-12-17T12:54:35Z

Are there any downsides of a universal binary? Does that even work 🤔? Otherwise, compiling a separate arm64 for MacOS is fine I think. wasm-pack can then just download the right binary for the platform.

dschuff · 2022-01-04T17:35:28Z

Universal binaries should work just fine; it's been a supported feature on macOS for a long time (previously used for 32 and 64-bit x86). The main downside (compared to having a package with just a single architecture) is that the binary is 2x as big. The advantage is that it's simpler to build and distribute, and potentially to download.

dschuff · 2022-01-05T18:21:48Z

Here's a hacky version with a separate package. @sbc100 do you know of a way to test this on Github Actions without actually creating a release tag?

sbc100 · 2022-01-05T18:30:45Z

Here's a hacky version with a separate package. @sbc100 do you know of a way to test this on Github Actions without actually creating a release tag?

I believe under the current setup all you need to do is create a dummy tag on this revision.. and the action will run creating a preview release (which you can then discard).

sbc100 · 2022-01-05T18:31:51Z

I don't think there is any need for a universal binary here. wasm-pack seems like its already setup to download and arch-specific, and not universal binary anyway.

dschuff · 2022-01-05T20:00:17Z

OK, I think this is doing what we want now. The only thing I don't really like about it is that I've basically just duplicated the whole archive step. That's not the worst thing, it isn't complex. But I don't know if there's a better way.

sbc100

There is probably a more elegant way to avoid the duplication here.. but I'm not sure its worth spending more time on.

sbc100 · 2022-01-05T20:13:59Z

.github/workflows/ci.yml

@@ -73,7 +73,7 @@ jobs:
      if: matrix.os == 'ubuntu-latest'

    - name: cmake (macos)
-      run: cmake -S . -B out -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=out/install
+      run: cmake -S . -B out -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=out/install -DCMAKE_OSX_ARCHITECTURES=x86_64


Technically the explicit architecture isn't needed, since x86_64 is the default (for now....). But making it explicit seems more understandable, and eventually I guess it will no longer be the default? If this is distracting I can take it out.

I think we should just leave it as the default.

sbc100 · 2022-01-05T20:14:08Z

.github/workflows/ci.yml

@@ -82,7 +82,7 @@ jobs:
      if: matrix.os == 'windows-latest'

    - name: build
-      run: cmake --build out --config Release
+      run: cmake --build out --config Release -v


Yes, but I actually prefer having automated build logs be as verbose as possible. It doesn't really cost anything and anytime you have to debug any issue, usually the first thing you have to do is reproduce it with verbose to see the flags.

What does -v do when running cmake exactly? We should probably use this flag everywhere or nowhere.

dschuff · 2022-01-06T01:09:46Z

Should we tag a new release now?

sbc100 · 2022-01-06T01:43:40Z

Should we tag a new release now?

Sure!

d3lm · 2022-01-06T11:16:53Z

Now that this is merged, does that mean there's a native arm64 release which can be used on an M1?

d3lm · 2022-01-06T11:18:25Z

I don't think there is any need for a universal binary here. wasm-pack seems like its already setup to download and arch-specific, and not universal binary anyway.

Yes, that's right. wasm-pack looks for an arch specific version and if there's an arm64 then I can submit a PR to wasm-pack to download that instead of the x86 version.

dschuff · 2022-01-12T21:57:00Z

Sorry, I just realized that nobody actually tagged a release. I just tagged version_105, it should be up on https://github.com/WebAssembly/binaryen/releases shortly.

d3lm · 2022-01-18T18:12:47Z

Thanks a lot 🙏

dschuff added 3 commits December 15, 2021 16:26

Try Arm64

39ec65f

verbose

821eeef

universal binaries

62c07ca

quote the flag

511b074

try separate packages

1ad2fab

dschuff added 4 commits January 5, 2022 10:36

make the CI a single-arch binary

9409192

fix mac run step

7f62f87

split output directory correctly

9441ee1

clear output dir before moving

da4cf35

dschuff requested a review from sbc100 January 5, 2022 20:00

dschuff changed the title ~~Build MacOS releases as universal binaries~~ Build ARM64 MacOS releases Jan 5, 2022

sbc100 reviewed Jan 5, 2022

View reviewed changes

sbc100 approved these changes Jan 5, 2022

View reviewed changes

dschuff merged commit 73897b0 into main Jan 6, 2022

dschuff deleted the arm branch January 6, 2022 01:09

Build ARM64 MacOS releases #4397

Build ARM64 MacOS releases #4397

Uh oh!

Conversation

dschuff commented Dec 16, 2021

Uh oh!

dschuff commented Dec 16, 2021

Uh oh!

d3lm commented Dec 16, 2021

Uh oh!

dschuff commented Dec 16, 2021

Uh oh!

kripken commented Dec 16, 2021

Uh oh!

dschuff commented Dec 16, 2021

Uh oh!

d3lm commented Dec 17, 2021

Uh oh!

dschuff commented Jan 4, 2022

Uh oh!

dschuff commented Jan 5, 2022

Uh oh!

sbc100 commented Jan 5, 2022

Uh oh!

sbc100 commented Jan 5, 2022

Uh oh!

dschuff commented Jan 5, 2022

Uh oh!

sbc100 left a comment

Choose a reason for hiding this comment

Uh oh!

sbc100 Jan 5, 2022

Choose a reason for hiding this comment

Uh oh!

dschuff Jan 5, 2022

Choose a reason for hiding this comment

Uh oh!

sbc100 Jan 6, 2022

Choose a reason for hiding this comment

Uh oh!

sbc100 Jan 5, 2022

Choose a reason for hiding this comment

Uh oh!

dschuff Jan 5, 2022

Choose a reason for hiding this comment

Uh oh!

sbc100 Jan 6, 2022

Choose a reason for hiding this comment

Uh oh!

dschuff commented Jan 6, 2022

Uh oh!

sbc100 commented Jan 6, 2022

Uh oh!

d3lm commented Jan 6, 2022

Uh oh!

d3lm commented Jan 6, 2022

Uh oh!

dschuff commented Jan 12, 2022

Uh oh!

d3lm commented Jan 18, 2022

Uh oh!

Uh oh!