summaryrefslogtreecommitdiffstats
path: root/Modules/Platform/Darwin-Initialize.cmake
Commit message (Collapse)AuthorAgeFilesLines
* apple: add preliminary visionOS supportGregor Jasny2023-07-111-1/+3
|
* enable_language: Establish target platform identification variables earlierBrad King2023-06-071-0/+3
| | | | | | | | Set target platform identification variables like `APPLE` and `LINUX` as soon as the target system is identified. This makes them available during toolchain and binutils selection. Fixes: #23333
* macOS: Offer control over host architecture on Apple Silicon hostsBrad King2020-12-101-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Apple: Update SDK architecture detection for tbd file version 4Tor Arne Vestbø2020-11-051-3/+9
| | | | | | 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.
* macOS: Default to arm64 architecture on Apple Silicon hostsBrad King2020-09-301-0/+11
| | | | | | | | 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
* macOS: Always pick latest SDK if user has not set one explicitlyTor Arne Vestbø2020-07-141-21/+12
| | | | | | | Apple tech note QA1806 recommends always building against the latest SDK. Fixes: #20949
* Darwin: prefix internal osx variables with "_" to hide them from usersChuck Cranor2020-07-031-9/+9
| | | | | | | | | | | | 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
* iOS: Fix detection of supported SDK architecturesAlexandru Croitor2020-04-161-11/+76
| | | | | | | | | | | | 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
* Apple: Improve handling of missing SDKs in CMAKE_APPLE_ARCH_SYSROOTSBrad King2020-04-081-2/+2
| | | | | | | | | | 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
* Handle multi-arch sysroots on Apple platformsTor Arne Vestbø2019-12-131-0/+79
|
* Refactor SDK name to path into a functionCristian Adam2019-12-111-11/+15
|
* Use xcrun instead of xcodebuild for resolving SDK pathTor Arne Vestbø2019-12-091-1/+1
| | | | It's much cheaper to run.
* Apple: Introduce separate system name for iOS, tvOS, and watchOSGregor Jasny2019-02-041-1/+7
| | | | | | | | | | | - 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: Use CMAKE_EFFECTIVE_SYSTEM_NAME to share compiler infoGregor Jasny2018-04-181-0/+4
| | | | | | | | | 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
* Darwin: Remove deployment target version checkGregor Jasny2016-11-011-2/+0
| | | | | | | | | | | | | | | | | | | | | 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 "Xcode: Convert maybe unversioned OSX sysroot into versioned SDK path"Gregor Jasny2016-11-011-4/+2
| | | | | | | | | | | | | | | 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
* OS X: Do not try to set deployment target when cross-compilingGregor Jasny2016-10-171-1/+1
| | | | | | | | | 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
* Xcode: Convert maybe unversioned OSX sysroot into versioned SDK pathGregor Jasny2016-09-251-2/+4
| | | | | | | | | | | | | | | | | | 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: Drop warning about SDK and deployment target version mismatchBrad King2016-05-261-10/+0
| | | | | | | | | 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>
* Xcode: Adjust deployment target SDK version to host versionGregor Jasny2015-10-121-0/+4
| | | | | | | | | | 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.
* Xcode: Find fallback SDK if one matching the OS version doesn't exist.Clinton Stimpson2014-05-061-14/+29
| | | | | | | | 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.
* OS X: Factor a Darwin-Initialize module out of Platform/DarwinBrad King2014-04-291-0/+136
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.
generated by cgit v0.12 at 2025-01-20 00:38:14 (GMT)