Support CMAKE_OSX_ARCHITECTURES

[alexreinking]

As requested at the last Halide dev meeting, I have drafted an implementation of support for CMAKE_OSX_ARCHITECTURES. This is again quite complicated, in part because I attempted to avoid breaking existing user code.

As it stands, multi-target alternative selection and feature specification are stepping on each others' toes.

I'll write more tomorrow.

Fixes #8134

---

Breaking suggestion:

• The TARGETS argument and the Halide_TARGET variable shall take only the following values:
  • host (passed verbatim to the generator, but resolved for feature selection)
  • cmake
  • ARCH-BITS-OS (a triple)
• When CMAKE_OSX_ARCHITECTURES is set, cmake expands to a list of compatible architectures, e.g. arm-64-osx;x86-64-osx. This is reflected in Halide_CMAKE_TARGET. host expands to a single triple corresponding to the architecture of the cmake executable itself (this enables compatibility with the arch command).
• The FEATURES argument applies a list of features to ALL alternatives on ALL platforms (useful for, e.g. user_context, name mangling, etc.)
• The FEATURES[platform] arguments set up a list of alternatives (e.g. FEATURES[x86-64-linux] "avx2-sse4" "sse4") for a particular triple.

What this doesn't resolve is how to do things like TARGETS cmake-no_bounds_query cmake effectively. Perhaps the following adjustments to the above help:

• Rename FEATURES[platform] to MULTITARGET[platform]
• Add MULTITARGET (unadorned) to provide the default value for unspecified [platform]s.

Specifying an empty entry in FEATURES/MULTITARGET or whatever is challenging in CMake because it really wants to drop empty function arguments. We might need to add a dummy feature like none (either in the actual Generator or just in the build system) that does nothing but isn't the empty string.

[alexreinking]

Topics for discussion at the dev meeting:

1. How to test this on CI?
2. How to test build sanity on iOS?

[alexreinking]

Finally, we have a clean build! The halide-asan test failure is due to an LLVM build bug that was fixed in a revert five days ago. Marking this as Ready for Review.

@derek-gerstmann -- I'd appreciate some help testing offline.

[derek-gerstmann]

Testing on my MacBook Pro M1 Max and everything appears to work! I agree, it'd be nice to find a testing strategy for both desktop and mobile.

[alexreinking]

From dev meeting:

• [x] Need to collect multiple extra-outputs in the output variables (how to test?)
• [x] Need to provide a way to generate the c sources as a byproduct, rather than going through the configured compiler
• [ ] Testing: have ARM builders be fat. Test with Rosetta, too.

[alexreinking]

This is ready on my end. @steven-johnson -- we should coordinate adding testing to the buildbots. Should we wait to land this until we have that?

[steven-johnson]

This is ready on my end. @steven-johnson -- we should coordinate adding testing to the buildbots. Should we wait to land this until we have that?

yes, probably

[alexreinking]

Is there documentation/README for this anywhere...?

No, not yet

[alexreinking]

Landing this with the caveat that it might need adjustment to support IOS cross-compilation via Xcode. At the moment it seems to have not broken existing workflows and has (locally) enabled universal builds on macOS.