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
Clarify the release note added by commit 8ac826a5f2 (GenEx: Fix
evaluation of $<CONFIG> on imported targets, 2025-07-30,
v4.2.0-rc1~439^2) to more precisely describe the behavior change.
See: https://discourse.cmake.org/t/15251/2
Since commit dade821948 (cmPolicies: Reduce boilerplate in policy table
entries, 2024-11-13, v4.0.0-rc1~481^2~3), or perhaps earlier formatting
changes, the `grep` performed by this test is non-functional.
Prior to f9bc615d (pchreuse: ban PCH reuse from targets which disable
PCH, 2025-06-15), using a target without PCH as a `REUSE_FROM` target
was not an error. Some projects had been doing this unknowingly.
Downgrade the fatal error into a warning so that such projects can at
least continue to build.
Fixes: #27316
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 `:`.
FASTBuild will replace `%1%` with
all the glob matches, which might
exceed command line limit on Windows.
Moreover, we don't need to pass all the
matches to the VerifyGlobs.cmake script.
Fixes: #27305
Refactoring in commit 998495cb49 (cmExportCommand: Port to
cmSubcommandTable, 2025-07-15) accidentally removed support for the
`EXPORT_LINK_INTERFACE_LIBRARIES` argument. Restore it with a test.
Fixes: #27302
Add an explicit check in `install(EXPORT)` that the export name is
non-empty. Since an empty-named export set will never exist, this is
always an error. Previously, however, the error would not be caught
until generate time. Now an error will be produced immediately.
If using both FindLua and FindLua51 modules, the FindLua51 and Lua 5.2
or newer is found, FindLua51 module can set the Lua_VERSION variable to
empty value. Instead, the Lua51_VERSION can be used to bypass this
issue.
Issue: #27088
* This module previously didn't define the OpenMP_VERSION result
variable.
* Added CMake versions to variables when they were provided by the
module.
* Synced docs.
* FindKDE4: Added note about KDE4_FOUND result variable (it is set by
the upstream FindKDE4Internal module, and now also synced in the docs
and code for consistency).
For the sake of completeness with other find modules, also the following
deprecated find modules are synced as they already provided these
variables:
* FindDart: Documented the Dart_FOUND result variable.
* FindUnixCommands: Updated documentation (documented UnixCommands_FOUND
result variable, and listed cache variables used by this module).
Issue: #27242
Fix two bugs from commit e301cbffcc (ExternalProject: Set environment
variables, 2025-04-09):
* Do not flatten lists in command arguments when adding env mods.
* Remove empty `COMMAND`s without injecting corresponding env mods.
Fixes: #27125Fixes: #27126
Co-authored-by: Brad King <brad.king@kitware.com>
A single executable for each policy/charset combination is sufficient.
The behavior is the same across target types.
The "OLD" cases are not needed because "WARN" has the same behavior.
The `-D` cases are not needed because `target_compile_definitions`
strips the `-D` prefix before populating `COMPILE_DEFINITIONS`.
Revert the regex change from commit 01147454e7 (FASTBuild: Add
generator, 2025-07-30) and revise the build output to match anyway.
The actual problem was that build and install steps are driven through
a nested `cmake --build`, and `fbuild` prefixes the first line of build
output. Add an innocuous first line so we can match the intended lines
consistently across generators.
Brad King