Add macOS arm64 support to 0.5.x

[alloy]

Summary

Build macOS artefacts for macOS 10.13 and with arm64 slices.

Test Plan

[alloy]

I changed this to be inline with the current version in this branch, but this should likely change before the actual release?

[alloy]

Ok, build is green. Will test on a DTK later today.

[alloy]

@Huxpro This is tested and good to go. The one thing that would need a change is the version, I guess it can just be v0.5.2 or v0.5.3?

[Huxpro]

@alloy hey i'm coming back to this!

The one thing that would need a change is the version, I guess it can just be v0.5.2 or v0.5.3?

Hm i'm not sure how does the arm64 support work to tell this. What does adding arm64 to the CMAKE_OSX_ARCHITECTURES do? It seems like there is still only one destroot/Library/Frameworks/hermes.framework/Versions/0/hermes in the hermes-runtime-darwin tarball built from the CircleCI of this PR, and it is still an x86_64 executable? (Well actually, I realized Idk anything about the darwin thing here...apparently it's different with the libhermes.so used by Android).

Basically, we used rc1 in the 0.5.2-rc1 for Proxy because it's an opt-in npm package instead of being a default. npm install hermes-engine@~0.5.0 can pick 0.5.2 but not 0.5.2-rc1.

So if the npm package after this PR can work for both x86 and ARM out of the box I will say 0.5.3. If it's not going to work with x86 I will say 0.5.3-blah (rc1, or mac-arm, idk) and let RN macOS ARM somehow opt in the hermes-engine@0.5.3-blah.

[alloy]

What does adding arm64 to the CMAKE_OSX_ARCHITECTURES do? It seems like there is still only one destroot/Library/Frameworks/hermes.framework/Versions/0/hermes in the hermes-runtime-darwin tarball built from the CircleCI of this PR, and it is still an x86_64 executable?

Mach-O binaries can be “fat” binaries, which mean they can contain multiple slices to support different architectures.

In the case of these artefacts:

$ file hermes-runtime-darwin-v0.5.2-rc1/destroot/bin/hermesc 
hermes-runtime-darwin-v0.5.2-rc1/destroot/bin/hermesc: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
hermes-runtime-darwin-v0.5.2-rc1/destroot/bin/hermesc (for architecture x86_64):	Mach-O 64-bit executable x86_64
hermes-runtime-darwin-v0.5.2-rc1/destroot/bin/hermesc (for architecture arm64):	Mach-O 64-bit executable arm64

$ file hermes-runtime-darwin-v0.5.2-rc1/destroot/Library/Frameworks/hermes.framework/Versions/0/hermes 
hermes-runtime-darwin-v0.5.2-rc1/destroot/Library/Frameworks/hermes.framework/Versions/0/hermes: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
hermes-runtime-darwin-v0.5.2-rc1/destroot/Library/Frameworks/hermes.framework/Versions/0/hermes (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
hermes-runtime-darwin-v0.5.2-rc1/destroot/Library/Frameworks/hermes.framework/Versions/0/hermes (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

So if the npm package after this PR can work for both x86 and ARM out of the box I will say 0.5.3.

Yup, it will work for both archs 👍

Basically, we used rc1 in the 0.5.2-rc1 for Proxy because it's an opt-in npm package instead of being a default. npm install hermes-engine@~0.5.0 can pick 0.5.2 but not 0.5.2-rc1.

Ah gotcha, good for me to at least understand the reason for that being a prerelease 👍

[Huxpro]

@alloy thanks for the elaboration! TIL the fat binaries!

Yeah then let's finalize this as 0.5.3 so we can have artifacts built with the correct version number ;)

[alloy]

Updated the versions to 0.5.3.