COMP: Pass macOS architecture settings to external projects

[vacaslistradas]

Summary

• Adds CMAKE_OSX_ARCHITECTURES, CMAKE_OSX_DEPLOYMENT_TARGET, and CMAKE_OSX_SYSROOT to ep_common_cache_args
• Fixes native ARM64 builds on Apple Silicon Macs

Problem

When building CTK with -DCMAKE_OSX_ARCHITECTURES=arm64 on a Mac with ARM64 Qt5, PythonQtGenerator fails to link:

ld: warning: ignoring file 'QtCore': found architecture 'arm64', required architecture 'x86_64'
ld: symbol(s) not found for architecture x86_64

Root Cause

The ep_common_cache_args variable (used by external projects like PythonQt and PythonQtGenerator) doesn't include macOS architecture settings, so nested projects default to x86_64 while trying to link against ARM64 Qt libraries.

Test Plan

• Built CTK with -DCMAKE_OSX_ARCHITECTURES=arm64 on macOS Tahoe (M4)
• PythonQtGenerator now builds successfully for ARM64
• Full CTK build completes without architecture mismatch errors

[jamesobutler]

You successfully built Qt5 from source for the arm64 platform? I don't believe Qt provides Qt5 arm64 binaries. And then you successfully built PythonQt for arm64 using that Qt5 build?

[vacaslistradas]

I didn't build Qt5 myself, Homebrew provides Qt5 5.15.16 pre-built for ARM64.
And yes, with this fix applied, PythonQt and PythonQtGenerator both build successfully for ARM64. The problem was that without passing CMAKE_OSX_ARCHITECTURES down to the external projects, the generator was building for x86_64 while trying to link against my ARM64 Qt5 libraries.

[hjmjohnson]

@jamesobutler This request seems reasonable, the solution looks good to me.

[jamesobutler]

@hjmjohnson As @pieper mentioned in Slicer/Slicer#9003 (comment), he seemed to not need any additional code changes in the context of Slicer and CTK to pass things down as his ARM64 build has already been successful without it.

[hjmjohnson]

@jamesobutler When environmental defaults are configured in a compatible way, there are no issues (i.e. when. the defaults are guessed correctly). I think this is a case of "not required when guesses are consistent, required when guesses are wrong".

Explicitly setting these variables is the safest and most robust approach. Let's make propagating these items more robust and only propagate them if they are set to non-null values.

I am a fan of being explicit when all the builds MUST use the same compilation environments/tools. Explicitly setting those values is often not needed in default builds, but it makes custom builds (i.e., old compilers/static analyzers/etc.) much easier to implement.

My hypothesis is that one of the environmental variables that changes the default behavior was set. I.e., they were trying to compile the following outdated slicer build instructions that changed defaults to x86_64, then started a new build, but forgot to unset the environmental variable. Then the Outer superbuild was set to arm64, but the inner build had to guess and used the environmental variable as the default.

I'm fine with this being ignored or incorporated, but I'd like a final decision.

[lassoan]

This looks good to me. Probably explicit propagation of these variables is not necessary in most cases, but it should not do any harm and it can be useful in some cases.