Since commit 474eafe28c (clang-cl: Add support for C++23, 2024-09-13,
v3.31.0-rc1~97^2) we use a Clang-specific flag to enable C++23 since
`clang-cl` has no `-std:c++23` flag, and `-std:c++latest` may enable an
even newer version of C++. However, in `.vcxproj` files there is no way
to express a target-wide `-clang:-std=c++23` flag for only C++ sources
when the target also has C sources. Add a special case to map back to
`-std:c++latest` for targets with C++23 and C together.
Fixes: #26508
Since commit e3895f4a8b (Linking: Preserve nested LINKER: prefixes as
written, 2024-09-17, v3.31.0-rc1~60^2) we may increment an iterator past
the end. Revise logic to avoid that.
Fixes: #26499
When `ui_` include directives have different paths than `CMakeLists.txt`,
the dependency graph is not generated correctly. This is the root cause
of #16776. However, when #26135 was fixed by commit 5363bebc1e (Autogen:
Fix compilation of unchanged source files, 2024-07-16, v3.31.0-rc1~328^2),
it made #16776 worse: the build is always dirty. Revert the fix for now.
Fixes: #26485
Issue: #26135
Issue: #25436
In commit 375e6fdbbe (Link step: use linker dependency linker file,
2023-04-19, v3.27.0-rc1~126^2) we added the `-Wl,--dependency-file,...`
flag for the Ninja generator in a code path shared with the file-api.
This flag is a build system implementation detail and should not be
exposed to file-api clients. Move it to a Ninja-specific code path.
Fixes: #26498
In commit 5363bebc1e (Autogen: Fix compilation of unchanged source files,
2024-07-16, v3.31.0-rc1~328^2) we relied on Ninja Multi-Config dependency graph
optimizations from commit 7c39dabdbc (Autogen: AUTO*_EXECUTABLE: add support
for per-config values, 2023-10-18, v3.29.0-rc1~105^2~1). However, those graph
optimizations are conditional on versions of Qt that enable
[`AUTOGEN_BETTER_GRAPH_MULTI_CONFIG`](https://codereview.qt-project.org/c/qt/qtbase/+/513648).
`UseBetterGraph` should be checked to add ui files to `timestampByproducts`.
Fixes: #26475
Teach `export()` and `install(EXPORT)` to record this setting on the
imported targets they generate. Make this property's non-presence
authoritative on imported targets since they represent what was built
elsewhere.
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8), the descriptors
for the `OUTPUT_FILE` and `ERROR_FILE` leak to child processes.
With `ExternalProject` + `INSTALL_COMMAND` + `LOG_INSTALL`, the logging
wrapper script leaks the log files' descriptors to the native build
tool. If they happen to match the `make` job server's pipe fds, e.g.,
with GNU `make` <= 4.3, then the build fails with an error like:
gmake[4]: *** read jobs pipe: Bad file descriptor. Stop.
Fixes: #26398
There is an inadvertent inconsistency in the notice for the CPS export
experimental feature as compared to other experimental feature notices.
Change it to be consistent.
Since commit 84db8506ff (Deprecate compatibility with CMake versions older
than 3.10, 2024-10-03, v3.31.0-rc1~23^2) the `cmake_minimum_required` and
`cmake_policy` commands warn if the project does not enable policies as
of 3.10 or higher. Clarify the advice given in the warning message about
how to update the version specification, particularly without actually
requiring a newer minimum version of CMake.
When a single-value keyword is repeated, and the first instance is
missing a value, it prevents the value from the second instance from
being stored in a variable. This was a regression introduced by
commit ceeea4e511 (cmake_parse_arguments: Set variable if empty string
given after keyword, 2024-08-18). That change also didn't create a
variable if the keyword was given but without a value. The purpose
of the change was to always define a variable if a keyword was given.
Lastly, that change didn't protect the CMP0174 logic to make it only
apply to the PARSE_ARGV form.
The first two of the above problems are fixed here by tracking the
keywords given instead of checking which keywords were missing
values. The third problem is also fixed here, being tightly coupled
to the same logic as the first two problems.
Fixes: #26397
Since commit 7abd3137b7 (Linking: Optionally reorder direct dependencies
from LINK_LIBRARIES, 2024-09-19, v3.31.0-rc1~53^2) the strategy name
`PRESERVE_ORDER` has led users to expect that it strictly preserves
order. While the part of the link line generation logic controlled by
`LINK_LIBRARIES_STRATEGY` does preserve order, it is not the last step.
Toolchain-specific de-duplication can cause the order to change on the
actual link line generated in the build system.
Rename the strategies:
* `PRESERVE_ORDER` => `REORDER_MINIMALLY`
* `REORDER` => `REORDER_FREELY`
The new names make it clear that reordering is always possible, just to
varying degrees. Update the `LINK_LIBRARIES_STRATEGY` documentation to
clarify that the strategies do not directly control the final link line.
Fixes: #26400
Issue: #26271
When using the WindowsKernelModeDriver, do not add the new paths
if the variable was not previously defined. Instead, append them
to the existing value.
Add a new GUID for the Experimental mode gate
The linker configuration file is now optional: It is loaded only if
variable CMAKE_<LANG>_USE_LINKER_CONFIGURATION is set to TRUE.
The file CMakeAddNewLanguage.txt is updated to take into account the
linker configuration.
Fixes: #26393
Fix a small bug in cmExportPackageInfoGenerator that caused extended
version properties ("compat_version", "version_schema")) to be emitted
when empty. Add a test to ensure this is working as intended.
Fixes: #26264
Revert commit 502610733f (Ensure imported targets in sibling dirs are
deduplicated, 2024-09-15, v3.31.0-rc1~92^2). Also revert the change
from a copy of the logic made by commit cd418d4bb6 (Static libraries
de-duplication: keep first occurrence, 2024-09-29, v3.31.0-rc1~30^2).
The logic was de-duplicating based on the target name rather than based
on the library file path.
Fixes: #26371
Issue: #26284
Re-introduce the behavior originally introduced in CMake 3.30.3 by
commit c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27, v3.30.3~2^2), but this time with a policy for
compatibility.
Issue: #25714
Issue: #26243
The change in commit 86ad7cc886 (project: Only define non-cache vars if
already defined, 2024-09-15, v3.30.4~2^2) was meant to only check for
non-cache variables when deciding whether to set non-cache project
variables for the current call. However, it erroneously checked for any
variable, including cache variables. This gives the intended result on
the first run, but on subsequent runs a cache variable will exist that
did not on the first run, leading to different behavior between the two
runs. Fix the logic to only check for a pre-existing non-cache
variable, as was originally intended.
Fixes: #26355
Brad King