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
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
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.
In commit 5de1e21659 (ctest: Allow passing -j without value to choose a
contextual default, 2024-03-06, v3.29.0-rc4~10^2) I misdiagnosed the
reason that the test could not set an empty environment variable on
Windows. It is actually a limitation of `set(ENV{VAR})` inherited from
its implementation using `_wputenv`. Process environment blocks can
contain empty environment variables.
Issue: #27285
aa5711490f set: Explicitly unset empty environment variables on Windows
723a83d8cd set: Factor out helper to set environment variables
20761cf349 set: Add test cases for setting ENV{VAR} to empty
a878d1c490 Tests: Unset the PATH environment variable more explicitly where needed
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !11290
The behavior differs by platform and if the variable is already set.
Encode existing behavior in tests to preserve it until intentionally
changed.
Issue: #27285
This adds the following new arrays, which together capture all direct
dependencies and interface dependencies of a target:
- linkLibraries
- interfaceLinkLibraries
- compileDependencies
- interfaceCompileDependencies
- objectDependencies
- orderDependencies
Fixes: #21995, #25213
Commit 62a1d3e7f1 (FileAPI: Add symbolic property to targets, 2025-09-30)
contained an error in added test code where a wrong library was linked.
The naming of the targets involved make clear the intended linking
relationship, but nothing in the test was actually testing or relying on
that relationship so it went undetected.
When targeting the MSVC ABI, define `_MBCS` by default if the project
does not define `_SBCS` or `_UNICODE`. Visual Studio has long defined
one of the three character set macros automatically. For consistency,
define it when compiling for the MSVC ABI with other generators.
Add policy CMP0204 for compatibility.
Fixes: #27275
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
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.
Adds support for "symbolic" components, which represent feature-level
capabilities of a package that do not correspond to actual build targets.
These are modeled as pseudo-targets, using the INTERFACE type as a base,
and can be queried via:
get_target_property(... <tgt> "SYMBOLIC")
This enables consumers to declare requirements on optional features
(e.g., SSL support) even when they do not map to concrete targets.
Fixes: #27187
Create a single place to store target data to prevent duplication.
This moves `targetType` and `targetLabels` out of the snippet files
and into a target map in the `cmakeContent` file referenced by each
snippet.
Fixes: #27244
Visual Studio defines this automatically for `.dll` targets.
For consistency, define it when compiling for the MSVC ABI
with other generators. Add policy CMP0203 for compatibility.
Fixes: #27253
Refactoring in commit 3882718872 (VS: Decouple solution generation from
`.sln` file format, 2025-09-15) accidentally left out automatic
detection of the external project type id from its file extension.
By default, .NET SDK-style projects build for "Any CPU", so we generate
solution files accordingly. Although CMake does not model per-target
architectures, some projects set the `VS_GLOBAL_PlatformTarget` property
on `DOTNET_SDK` targets in order to compile for a specific architecture.
Fix generated solution files to account for the architecture override.
Issue: #23513
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
