In commit 64821d8a26 (cmFileLockResult: Remove expensive windows.h
include, 2023-06-16, v3.28.0-rc1~446^2~13) we accidentally capitalized
the name of the header. This matters when cross-compiling from a host
with a case-sensitive filesystem.
Fixes: #25474
80fe56c481 ctest: Add support for running under a make job server on POSIX systems
5396f4a9a3 cmUVJobServerClient: Add libuv-based job server integration client
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9021
The operator added by commit 17690558c3 (cmUVHandlePtr: Add explicit
conversion to bool, 2023-10-26) works in direct expressions like
`if(foo)` but not compound expressions like `if(foo && ...)`.
Drop the `explicit` mark when compiling with Oracle Studio so we
can at least compile valid code.
Commit f2617cf8e6 (Source: Add cmInstallRuntimeDependencySet,
2021-05-19) introduced via !6186 to 3.21 added storage to the global
generator for runtime dependency sets. However, this was not cleared at
the start of configure in the `ClearGeneratorMembers()` method. When
using `ccmake` to configure (and, presumably `cmake-gui` too), projects
using `install(TARGETS … RUNTIME_DEPENDENCY_SET)` would use dependency
set tracking instances from previous configure runs that held references
to targets free'd with the `cmMakefile` instance that held them.
Clear the dependency sets at the beginning of configure so that they are
not remembered and trigger via use-after-free bugs when used.
Fixes: #25446
Tell users what generators *do* support C++ modules. Report the current
generator to make clear it is not one of those supporting modules.
Also clarify the purpose of the existing documentation references.
Fix commit e40d2cb3af (Xcode: Add embed resources support, 2023-07-31,
v3.28.0-rc1~281^2). The implementation should not name the `_PATH`
suffix explicitly. That variant is automatically handled by
`cmGlobalXCodeGenerator::AddEmbeddedObjects`.
0432b921ae cmCTestMultiProcessHandler: Inline removal of pending test as it starts
b17c732e88 cmCTestMultiProcessHandler: Clarify role of StartTestProcess
0950acb337 cmCTestMultiProcessHandler: Manage concurrency slots with other resources
697900da29 cmCTestMultiProcessHandler: Manage affinity assignments with other resources
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8999
Makefiles do not have a per-object sense of where they come from, so
forwarding any module information here would end up with incorrect
module file path construction by consuming targets. Leave a TODO item in
its place.
Fortran modules provided by objects added as linked items via
`$<TARGET_OBJECTS>` should also be considered as "linked targets" for
collation purposes. As C++ modules have their own visibility rules
through their `FILE_SET` feature, do not expose these for C++ module
collation.
When a target uses objects from another target which provides modules as
sources, the modules provided by the referenced target must also be
treated as if they were provided by the referencing target. Add the
concept of "forwarding" modules so that consumers can use modules
created by these sources as well.
Note that this is only sensible for Fortran where module usages are
implicit as far as CMake's visibility model is concerned. C++ modules
have their own concept of visibility which does not require or support
such `$<TARGET_OBJECTS>` reuse in this way.
Brad King