Switch macOS multi-arch to x86_64+arm64

[achernya]

The previous CI attemtped to use Homebrew for builds, but
unfortunately Homebrew has dropped support for universal packages aka
multiarch (fat) binaries. This means that in order to build an arm64 +
x86_64 package, macports has to be used instead of homebrew.

Unlike Homebrew, MacPorts is not installed by default on the GitHub
Actions runners, so we need to install it ourselves. This means
managing our own instance of the cache, which itself produces
challenges as the gtar binary run by the action doesn't have enough
permissions to restore the MacPorts checkout. So we have to shim gtar
with a sudo wrapper.

With this commit, we produce a Mosh package that works on macOS 11.0
and newer, on both arm64 and x86_64 architectures. The protobuf
library is statically linked, but all other libraries are provided by
the system.

[carlocab]

You can keep using brew with a statically linked protobuf by provisioning your own universal libprotobuf.a using thin versions provided by Homebrew.

I did something similar for Neovim recently; see: https://github.com/neovim/neovim/blob/946c8fd2886df9db288797c257bf067b904a3551/.github/workflows/release.yml#L88-L106

Of course, if you're happy with using MacPorts, that works too.

[achernya]

Thanks for the suggestion @carlocab. I'm a bit uncomfortable running lipo on build objects we didn't produce, and I think macports is acceptable. I will definitely keep this solution in mind if we run into issues with macports and need to go back to homebrew.

[carlocab]

Sure, no problem!

Out of curiosity, do you mind sharing your concerns about using lipo?

[achernya]

I don't have a concern with lipo in general. We use it in mosh's own build process. I am just slightly wary of using it on build products that we aren't directly responsible for.

[carlocab]

I am just slightly wary of using it on build products that we aren't directly responsible for.

Yes, these are the concerns I was wondering about. (Feel free to say that you have no time or interest to talk about them them.)

[achernya]

I unfortunately don't have a more detailed concern. It's mostly that it feels like an abstraction violation on that the binary merge there with lipo should have been done by the packaging system if that was something it supported. I don't really know as a library consumer if the build settings of the two architectures here are compatible, since it's not documented as explicitly supported. Certainly if homebrew said this was supported I'd feel comfortable using it.

[carlocab]

That makes total sense. Thanks for explaining!

[bbarenblat]

If you want to avoid a fork here, arch=${triple%%-*} does the same thing.

[achernya]

I personally find the bash string-substitution syntax harder to read, and the fork isn't that costly, so I prefer to leave this one as-is.