b1fdab3cc1 source: Pass small and trivially copyable types by value
7829ea76ad source: Pass cmFileTime by value
99c10afc26 source: Pass trivial dap::*Event by value
0bcb8d6e3c source: Pass cmFileAPI::Object by value
964e992ec5 source: Pass cmCTestResourceAllocator::Resource by value
ee1c32b6d7 source: Pass cmBuildOptions by value
fa0e5906ff source: Pass cmStringRange by value
0c4040057a source: Pass cm::string_view by value
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10948
b51127249e ci: Enable -Wstrict-prototypes in tests for merge request pipelines
58d5f34d31 Replace deprecated -Werror-implicit-function-declaration with -Werror=
78c0935c9b Enable -Wundefined-func-template when building CMake's C++ code
2c6dde430a Enable -Wstrict-prototypes when building CMake's C code
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10983
Enable it in Makefile generator jobs that run in merge requests.
In particular, this causes RunCMake tests to fail if they build
C code with a missing function prototype because the compiler's
stderr reaches RunCMake's checks. Catch this before staging.
Skip enabling this in the Fedora+Makefiles job because Fedora's GCC
now defaults to C23 under which -Wstrict-prototypes does not warn.
Suggested-by: Matthew Woehlke <matthew.woehlke@kitware.com>
11ee18b758 ci: extend msvc_v71_nmake `RunCMake.PrecompileHeaders` test timeout
1c91fadbe8 Tests/RunCMake/PrecompileHeaders: support extended timeout
42f2867b3b pchreuse: defer dependency addition until generation time
f9bc615d9a pchreuse: ban PCH reuse from targets which disable PCH
f78f592b78 pchreuse: defer target existence enforcement to generation time
3ef773490d pchreuse: defer PCH consistency checks to generation time
1d701491a2 pchreuse: always ask the PCH reuse target for PDB information
6e7da8aa95 cmGeneratorTarget: factor out reuse target computation
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: alcroito <alexandru.croitor@qt.io>
Acked-by: Vincent X <gulackeg@gmail.com>
Merge-request: !10887
Revert commit 31884a7146 (ci: Add nightly job to build CMake with
vendored curl on macOS, 2024-05-09, v3.30.0-rc1~130^2). After
curl 8.15.0 dropped support for the Secure Transport backend, we
rely on the curl provided by macOS to use the system certificate
store.
Although there is no `cl -std:c23` flag, the underlying Clang compiler
does have a C23 mode we can activate by passing `-std=c23` through a
`clang-cl` wrapper flag.
Also port the fix from commit 30139913e9 (VS: Restore support for mixing
C++23 and C in one target with clang-cl, 2024-12-09, v3.31.3~10^2).
Fixes: #27038
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Co-authored-by: Brad King <brad.king@kitware.com>
e37a40442a ci: Update Windows builds to MSVC 14.44 toolset
c955d5c31f ci: Tie Intel 2024.1 jobs on Windows to MSVC 14.43 toolset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10802
e37a40442a ci: Update Windows builds to MSVC 14.44 toolset
c955d5c31f ci: Tie Intel 2024.1 jobs on Windows to MSVC 14.43 toolset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10802
We've removed use of KWSys ConsoleBuf in post-4.0 commit 3e88020aed
(StdIo: Replace uses of KWSys ConsoleBuf with StdIo::Console,
2025-05-08). There is no need to run its test anymore.
Windows-Terminal-Issue: https://github.com/microsoft/terminal/issues/18748
Drop the patch step from commit 919de8785b (ci: Patch HDF5 Fortran
compiler wrappers in Fedora jobs, 2023-03-30, v3.27.0-rc1~242^2~1).
Fedora 42's HDF5 packages fixed the problem.
Our Linux CI jobs incidentally run as `root` in their containers, but
do not need any superuser tools. Drop `sbin` entries from the `PATH`.
This also avoids finding user tools through Fedora 42's `sbin -> bin`
symbolic links.
dfe3b98387 Merge branch 'backport-ci-cuda' into ci-cuda
72e7636540 ci: add tags to tie CUDA jobs to runners with hardware supporting them
1395c1e19a ci: Tell CudaOnly.Architecture test what specific architecture to use
4f2178c4a8 ci: add tags to tie CUDA jobs to runners with hardware supporting them
63a5460faf ci: Tell CudaOnly.Architecture test what specific architecture to use
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10691
CUDA 12.8 deprecated support for compute architectures below 75.
Presumably support will be removed from a future version of the
CUDA Toolkit. Jobs using such a future version of CUDA will not
be able to compile support for CUDA architectures below 75, so
they will not be able to run on older hardware. In preparation,
our CI runners now have `cuda-arch-#` tags for the architectures
they support. Jobs may then be tagged with the minimum architecture
on which they can run.
Tag each job with the highest of the following requirements:
* Most of CMake's tests use the CUDA compiler's default architecture,
which is based on the version the CUDA toolkit.
* For Clang we currently select architecture 52 if supported by the
CUDA toolkit, even if that toolkit's NVCC defaults to an older arch.
* The `CudaOnly.Architecture` test uses a specific architecture
configured by each CI job.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 52 in this test.
CUDA 12.8 deprecated support for compute architectures below 75.
Presumably support will be removed from a future version of the
CUDA Toolkit. Jobs using such a future version of CUDA will not
be able to compile support for CUDA architectures below 75, so
they will not be able to run on older hardware. In preparation,
our CI runners now have `cuda-arch-#` tags for the architectures
they support. Jobs may then be tagged with the minimum architecture
on which they can run.
Tag each job with the highest of the following requirements:
* Most of CMake's tests use the CUDA compiler's default architecture,
which is based on the version the CUDA toolkit.
* For Clang we currently select architecture 52 if supported by the
CUDA toolkit, even if that toolkit's NVCC defaults to an older arch.
* The `CudaOnly.Architecture` test uses a specific architecture
configured by each CI job.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 52 in this test.
2e59cee922 FindXCTest: Fix test module generation for Xcode 16
c653c1aa47 FindXCTest: Pass -bundle_loader linker flag for test module more reliably
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10573
2e59cee922 FindXCTest: Fix test module generation for Xcode 16
c653c1aa47 FindXCTest: Pass -bundle_loader linker flag for test module more reliably
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10573
In Xcode 7.3 and above, the `TEST_HOST` setting causes Xcode to
implicitly place the test module inside the executable bundle regardless
of the module's own location settings. Since commit a364d2513a (Xcode:
Fixup XCTest bundle location for Xcode 7.3, 2016-03-25, v3.5.2~6^2) we
explicitly tell CMake to put the test module in the same location so
that generator expressions used by `xctest_add_test` agree with where
Xcode actually puts it. In Xcode 16 and above, our explicit location
settings for the test module conflict with Xcode's `TEST_HOST` rules,
causing errors about multiple commands producing the same path.
Fix this by dropping CMake's explicit location for the test module
unless needed to match a project-specified location for the testee.
Instead, teach `xctest_add_test` to express the xctest module location
selected by `TEST_HOST` by using generator expressions referencing the
testee bundle.
Fixes: #26301Fixes: #26514
Components are added in a backward-compatible way:
* ASPELL component - adds the ASPELL::ASPELL imported target
* Executable component - adds the ASPELL::Executable imported target
If components are not specified in find_package() call, module, by
default, searches for both components and provides backward
compatibility with the find_package(ASPELL) usage via ASPELL_LIBRARIES,
ASPELL_INCLUDE_DIR, and ASPELL_EXECUTABLE variables.
The ASPELL_DEFINITIONS variable description removed from the
documentation as it was never defined by this module.
Additionally added a Pspell interface check (pspell.h header file) if
Aspell library provides it. It is checked separately because it might
be located in a subdirectory of pspell/pspell.h and code includes it as
`<pspell.h>`. Some distributions package pspell.h as part of the
libpspell development package and install also libaspell development
package as a dependency for BC.
Added also ASPELL_VERSION variable in case aspell executable can
determine it.
Issue: #26811
Brad King