61d0bdf6b7 macOS: Avoid relying on sw_vers when cross-compiling from another OS
d9d65ab54f macOS: Remove outdated condition for CMAKE_OSX_DEPLOYMENT_TARGET
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11340
We have a few code paths needed only to support builds hosted on
macOS 10.4. Update the conditions to work when cross-compiling
to macOS from another platform.
This backports commit eb8facd396 (macOS: Avoid relying on sw_vers
when cross-compiling from another OS, 2025-04-28, v4.1.0-rc1~260^2)
to CMake 4.0.
Fixes: #26814
Revert commit 2853326e7a (BUG: Only set CMAKE_OSX_DEPLOYMENT_TARGET on
Mac OSX 10.4 or later, 2009-01-27, v2.8.0~1169). AFAIK no one is using
macOS versions older than 10.4 anymore.
This backports commit 476b2a386f (macOS: Remove outdated condition
for CMAKE_OSX_DEPLOYMENT_TARGET, 2025-04-28, v4.1.0-rc1~260^2~1)
to CMake 4.0.
Backport commit 79a83ddb08 (Apple: Enable linking during
iOS/tvOS/visionOS/watchOS toolchain inspection, 2024-11-14,
v4.0.0-rc1~471^2) to 3.31.
Since commit 11da882a12 (Apple: Introduce separate system name for iOS,
tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) our toolchain
inspection steps, like ABI detection, tell `try_compile` to use a
`STATIC_LIBRARY` instead of an `EXECUTABLE`. This was needed at the
time to avoid codesign requirements. However, commit d3a64c4e3f (Xcode:
Explicitly turn off signing in try_compile projects, 2020-07-16,
v3.19.0-rc1~483^2) introduced a more general solution to that problem.
Restore linking during toolchain inspection so that we can detect and
identify the linker.
Suggested-by: Marc Chevrier <marc.chevrier@gmail.com>
Fixes: #26443
Since commit 13c7bb5b0c (cmGeneratorExpression: Update strip function to
collect parsed expressions, 2025-04-08, v4.1.0-rc1~361^2~1), the logic
to strip generator expressions would error if the stripped expressions
were being collected and an expression without a `:` was found inside an
expression with a `:`. This resulted in an error when exporting a target
that contained such a generator expression in its link libraries or
compile definitions.
Address the error by checking whether the latest `$<` proceeded the
latest `:`.
9d302ecd47 ci: update macOS jobs to use Xcode 26.0 in CMake 3.31 branch
f6f1c5ca1f Tests: Teach RunCMake to ignore Xcode an IDERunDestination warning
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11292
On some Xcode versions, `xcodebuild` may warn:
... xcodebuild[...] IDERunDestination: ...
Teach RunCMake to drop such incidental lines before matching against
expected output.
Backport commit edaa6ed06a (Tests: Teach RunCMake to ignore Xcode an
IDERunDestination warning, 2025-09-19, v4.1.2~9^2~1) to CMake 3.31.
When a variable ends with a newline, the Ninja generator escapes it as
expected with `$\n`. However, when writing it out, whitespace is
trimmed. This leaves a trailing `$` instead which consumes the newline
and masks the following stanza. In a custom command, this hides the
`restat = 1` setting.
Detect this case and restore the newline as necessary.
See: #25983
In commit 9d44a77454 (find_*: Explicitly normalize found paths as they
exist on disk, 2024-10-17, v4.0.0-rc1~597^2~1), we removed path
normalization from the internal `cmSearchPath::AddPathInternal` helper.
Most call sites were updated to normalize input paths first, but search
paths derived from `<PackageName>_ROOT` CMake variables are no longer
normalized. Instead we normalize the path to the file found after
searching.
When `find_package` "config" mode considers a candidate CMake package
configuration file, normalize its path before loading the adjacent
package version file so that the latter is loaded by absolute path.
Otherwise `cmMakefile::ReadDependentFile` interprets a relative path
with respect to the current source directory rather than the current
working directory.
Fixes: #27279
In commit 9d44a77454 (find_*: Explicitly normalize found paths as they
exist on disk, 2024-10-17, v4.0.0-rc1~597^2~1), we removed path
normalization from the internal `cmSearchPath::AddPathInternal` helper.
Most call sites were updated to normalize input paths first, but search
paths derived from `<PackageName>_ROOT` CMake variables are no longer
normalized. Instead we normalize the path to the file found after
searching.
When `find_package` "config" mode considers a candidate CMake package
configuration file, normalize its path before loading the adjacent
package version file so that the latter is loaded by absolute path.
Otherwise `cmMakefile::ReadDependentFile` interprets a relative path
with respect to the current source directory rather than the current
working directory.
Fixes: #27279
Since commit 3e6466eb16 (find_package: Honor version requests when
finding CPS packages, 2025-02-12, v4.0.0-rc1~16^2) the test has relied
on `.*` to absorb capitalized paths on case-insensitive filesystems.
Match them explicitly.
In general we disallow references to transitive target properties, such
as `COMPILE_DEFINITIONS`, in `[INTERFACE_]LINK_LIBRARIES` properties,
because the latter establish the transitivity itself. Prior to CMP0189,
the `[INTERFACE_]LINK_LIBRARIES` properties were not themselves transitive
in `$<TARGET_PROPERTY>` expressions, so existing projects have code like
target_link_libraries(foo PRIVATE "$<TARGET_PROPERTY:tgt,LINK_LIBRARIES>")
Policy CMP0189's NEW behavior, introduced by commit b3da9c6d60 (GenEx:
Evaluate LINK_LIBRARIES target properties transitively, 2025-02-24,
v4.1.0-rc1~731^2), makes `$<TARGET_PROPERTY:tgt,LINK_LIBRARIES>`
transitive, causing the above to be rejected. Since evaluation of a
target's link libraries can already encounter and handle other targets'
link libraries, allow it in this case.
Fixes: #27265
Policy CMP0189, introduced by commit b3da9c6d60 (GenEx: Evaluate
LINK_LIBRARIES target properties transitively, 2025-02-24,
v4.1.0-rc1~731^2), takes effect at generation time, and so uses the
policy value as of the end of each directory. However, some projects
may rely on `file(GENERATE)` with the policy's OLD behavior in order
to extract targets' *direct* dependencies from `LINK_LIBRARIES`.
Pending a first-class solution to that problem, make it easier for
projects to port to the policy's NEW behavior in general while
retaining the OLD behavior in an isolated context.
Fixes: #27220
