Native Mac M1 Build via Clang-15

[dr7ana]

TODO

Clang-15 now supports native build on M1, so we might not have to lipo two binaries together. However, this will require refactoring all the mac build scripts and re-configure all dependencies; this will save a lot of headache down the line

Continues: #2074

[jagerman]

Clang-15 now supports native build on M1, so now we don't have to lipo two binaries together.

I'm not following how this helps. With -march=native then when we build on an Apple M1 we'll get an M1 build, and on amd64 we'll get an amd64 build, but for distribution we still need to build both (and then lipo the binaries together) to get one binary containing native builds for both architectures.

[jagerman]

(Also Apple is deliberately obtuse about which version of Clang actually backs AppleClang: they basically purge the upstream clang versions out of it entirely (even including the clang version macros) and replace them with their marketing versions which is a huge pain in the ass for developers, but as usual, Apple doesn't care about developers, probably ever since Ballmer started talking about developers).

[dr7ana]

Certain dependencies would definitely have to be compiled and lipo'ed twice

I was thinking that it would simplify at least the initial invocation by being able to pass --arch=native and --target=x86_64-apple-darwin20 for example. We can also pass two --arch flags to the clang command, like --arch=native --arch ${whatever is not native}

RE apple-clang vs other clang: Moving to Clang-15 (only available via Brew and MacPorts) seems to make sense to me? We could introduce logic to check which clang is being used and optimize for that. WDYT

[majestrate]

if we pass -march=x86_64-whateer and -march=m1-whatever then lipo them together it can compile on both kinds of macs for both kinds of macs. the underlying issue we hit was that xcode wont propagate the magic it does to do their hybrid compile stuff into the autotools static deps without us hacking together some dark magic to make cmake play nice with the xcode generator.

we gave up trying to make the xcode generator for cmake work on all our code bases because we personally got burnt out from doing so. this reluctance of doing it certain ways on mac mainly is derived from just not wanting to ever have to open xcode if we dont have to. this has made it possible to have a ci pipeline for macos in the long run. we prefer macports for this reason as our ci pipeline runs it. i am open to making homebrew work too so users can use that if they wish, i just dont think it is a sensible default for who we had working on mac (jason).