Since commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple
Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect
that we are running on Apple Silicon in a way that pierces Rosetta.
This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such
hosts. However, macOS offers strong support for running processes under
an emulated `x86_64` architecture.
Teach CMake to select either `arm64` or `x86_64` as the host
architecture on Apple Silicon based on the architecture of its own
process. When CMake is built as a universal binary, macOS will select
whichever slice (architecture) is appropriate under the user's shell,
and `CMAKE_HOST_SYSTEM_PROCESSOR` will match.
Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment
variable to provide users with explicit control over the host
architecture selection regardless of CMake's own architecture.
Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to
the toolchain to use selected host architecture instead of letting the
toolchain pick.
Fixes: #21554
Extend the `.tbd` parsing from commit 170e598add (iOS: Fix detection of
supported SDK architectures, 2020-04-16, v3.17.2~11^2) to support `.tbd`
file version 4.
Detect `arm64` hardware using a method that pierces Rosetta. If
`CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to the
toolchain to use `arm64` instead of letting the toolchain pick.
Fixes: #20989
A simple CMakeLists.txt on osx shows that variable "d" is set
(but empty) by the system modules. this pollutes the user's
variable namespace. I noticed this when I created a library
target "d" and got unexpected policy CMP0054 warnings when
trying to find_package(d CONFIG REQUIRED) (triggered from the
generated "d-targets.cmake" ...). Note that non-"_" prefixed
internal variables are ok within functions due to scoping rules.
Fixes: #20898
Instead of relying on SDKSettings.plist which does not contain the
certain architectures, deduce the supported architectures by
inspecting libSystem.tbd and libSystem.dylib.
.tbd files are text files, so just parse out the archs string.
.dylib files can be fat or non-fat, so use lipo -info to extract
the architectures and parse lipo output.
Fixes: #20588
Use `<arch>-SDK-NOTFOUND` instead of an empty string as a placeholder in
`CMAKE_APPLE_ARCH_SYSROOTS` for architectures whose SDK is not found.
This ensures the length of `CMAKE_APPLE_ARCH_SYSROOTS` matches the
length of `CMAKE_OSX_ARCHITECTURES`. It also makes the missing SDKs
more visible in the value.
Issue: #20534
- Remove code signing requirements for non-macOS
- Do not set deployment target for non-macOS
- Build static library for compiler feature detection for non-macOS
- Use framework to run CompilerId tests for watchOS
- Port tests to new SDK handling
- Add new Apple cross-compiling section to toolchain documentation
Closes: #17870
Apple platforms macOS, iOS, tvOS, and watchOS can all share the same
compiler information. Rename `Darwin-*` modules to `Apple-*` and load
them all through `CMAKE_EFFECTIVE_SYSTEM_NAME`. This saves duplication
of 4 * 21 compiler information modules.
Issue: #17870
Starting with Xcode 8 the SDK folder also contains an unversioned entry:
MacOSX.sdk
MacOSX10.12.sdk -> MacOSX.sdk
If this unversioned path is used CMake cannot detect the SDK version.
Furthermore, querying the SDK version via
xcodebuild -sdk <sysroot> -version Path
gives bogus results for the Command Line Tools installed into `/`.
The OS X deployment target version and SDK version are not as tied as
they once were, so this check is now more trouble than it is worth.
Simply remove it.
Closes: #16323
Revert commit v3.7.0-rc1~48^2 (Xcode: Convert maybe unversioned OSX
sysroot into versioned SDK path, 2016-09-25). The replacement of
`else()` with `if(CMAKE_OSX_SYSROOT)` defeats the prior handling of
`if("x${CMAKE_OSX_SYSROOT}" MATCHES "/")`. This causes the combination
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING="" -DCMAKE_OSX_SYSROOT:STRING=/
to not be honored and `-isysroot` to be emitted as a compiler flag
universally. We will need another solution to the problem the
now-reverted commit was meant to address.
Closes: #16394
The change in commit v3.4.0-rc2~6^2 (Xcode: Adjust deployment target SDK
version to host version, 2015-10-11) does not make sense when
cross-compiling. Make it conditional to fix this regression in some
cross-compiling cases.
Closes: #16355
Starting with Xcode 8 the SDK folder also contains an unversioned
entry:
$ ls -l /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
drwxr-xr-x 5 root wheel 170 Mar 4 2018 MacOSX.sdk
lrwxr-xr-x 1 root wheel 10 Sep 16 20:49 MacOSX10.12.sdk -> MacOSX.sdk
If this unversioned path is used CMake cannot detect the SDK
version. To work around the problem we always invoke the code path
that translates short SDK names like "macosx10.12" into a path.
That way we always end up with a versioned SDK path in
_CMAKE_OSX_SYSROOT_PATH which is later used to determine the version.
Closes: #16323
OS X supports using the SDK for any version equal to or newer than
the deployment target. There is no reason to warn if the versions
do not match exactly.
Suggested-by: James Burgess <jamesrburgess@mac.com>
Suggested-by: Clinton Stimpson <clinton@elemtech.com>
If the automatically selected SDK is newer than the host OS version
and no deployment version has been set then adjust the deployment
version to the host OS version. Otherwise the user won't be able to
launch the executables on the build host.
This is for example a problem on a MacOSX 10.10 host with Xcode 7
which only provides a MacOSX10.11 SDK.
For example if one installs Xcode 4.6 on OS X 10.9, it doesn't contain
a 10.9 SDK, so fallback to the next newest version which, in this case,
happens to be a 10.8 SDK.
This fixes bug #14572.
Initialize variables CMAKE_OSX_SYSROOT, CMAKE_OSX_DEPLOYMENT_TARGET, and
CMAKE_OSX_ARCHITECTURES prior to enabling any languages. This will
allow compiler identification to consider these values.
