437280b127 cxxmodules: scan C++ sources for imports by default
3cddd11649 Ninja: message about not compiled sources explicitly
068fde1c34 cmGeneratorTarget: use `this->` for method calls
197a6bf171 cxxmodules: rework control logic for scanning regular C++ sources
5eb7bd641a Tests/RunCMake/CXXModules: remove rules file requirement
ff18acc301 CXXModules: remove `EXPERIMENTAL` from C++ module variable names
0c07f39006 cmExperimental: remove the flag for C++ modules
68caec9137 Help: add a manpage for cxxmodule support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Pavel Solodovnikov <hellyeahdominate@gmail.com>
Merge-request: !8828
6546aa2a2a ci: Add HIP job using CUDA on NVIDIA GPUs
18158bf81c HIP: Add support for NVIDIA GPUs
127b6fa06b HIP: Add CMAKE_HIP_PLATFORM variable to specify GPU platform
90e23f40ee Tests/HIP/WithDefs: Clean up test case
9ebdf3281f Tests/HIP/ArchitectureOff: Cover HIP_ARCHITECTURES initialization
cfec29196e ci: Add CUDA 11.8 to HIP 5.5 image
26470eb987 ci: Put HIP GPU platform in CMake_TEST_HIP
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8817
This requires knowing when a generated header is public, which we can
model using file sets. Add policy CMP0154 to treat generated sources
as private by default in targets with file sets. Generated public
headers can be specified in public file sets.
Fixes: #24959
Issue: #15555
Since commit ffc06c1239 (Teach find_(library|file|path) to get prefixes
from PATH, 2015-02-18, v3.3.0-rc1~430^2) we search in `<prefix>/include`
and `<prefix>/lib` directories for prefixes with `bin` directories in
the `PATH` environment variable. The motivation was to search the
installation prefixes of MSYS and MinGW development environments
automatically.
This behavior can search undesired prefixes that happen to be in the
`PATH` for unrelated reasons. It was reverted for non-Windows hosts
within a year by commit b30b32a493 (Drop find_(library|file|path)
prefixes from PATH on non-Windows, 2016-05-09, v3.6.0-rc1~82^2) but was
kept on Windows hosts to support its motivating use case. However,
similar problems have since been observed on Windows. For example,
commit 955d6245c1 (MSVC: Revert "Teach find_library to consider the
'libfoo.a' naming convention", 2022-11-28, v3.25.1~6^2) was primarily
due to undesired discovery of libraries in `PATH`-derived prefixes.
Since commit 5e5132e1b1 (MinGW: Search for packages in standard MSYSTEM
environment prefixes, 2023-09-11) we search MSYS and MinGW environments'
prefixes explicitly, so `PATH`-derived prefixes are no longer needed for
the original motivating use case.
Fixes: #24216
MSYS2 and similar MinGW/MSYS distributions define development
environments with a `MSYSTEM` environment variable. Each such
environment has a documented installation prefix for its packages,
often provided by a `MSYSTEM_PREFIX` environment variable.
Since commit 84a25fc263 (cmake_host_system_information: Add
MSYSTEM_PREFIX query, 2023-09-08) we can look up this prefix.
Add `$MSYSTEM_PREFIX/local` and `$MSYSTEM_PREFIX` to our system search
prefixes when targeting MinGW under `MSYSTEM` environments. This is
their equivalent to `/usr/local` and `/usr`, which we search by default
on UNIX systems.
Issue: #24216
Many modern code editors have support for JSON Schema. When you specify
the `$schema` property in a JSON file, the editor can provide features
like auto-completion, error checking, etc., which can improve your
efficiency when writing and modifying the `CMakePresets.json` file.
With Xcode 14 support for the Legacy Build System has been removed
and the BuildSystemType in the WorkspaceSettings is ignored.
If CMake still generates projects targeted to the Lecacy Build
System the build preparation phase will likely fail because Xcode
for example misses any declared outputs from script invocations.
This is a hard to debug problem and CMake should reject the invalid
configuration instead.
Update the centos base image from centos 6 to centos 7. The latter is
the minimum version supported by libuv 1.45. The resulting binaries
require GLIBC 2.17.
Introduces `BUILD_JOB_SERVER_AWARE` option to `ExternalProject_Add` and
`JOB_SERVER_AWARE` to `ExternalProject_Add_Step`. When using an explicit
`BUILD_COMMAND` or `COMMAND`, the generated commands won't use `$(MAKE)`
thus failing to connect to the outer make's job server. These new
options enable explicit job server integration.
Co-authored-by: Brad King <brad.king@kitware.com>
Fixes: #16273
