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
Split packaging on Windows into dedicated jobs that run with access to
an EV signing certificate.
Prior to commit 0929221ca3 (gitlab-ci: Simplify Windows packaging
pipeline, 2023-02-28, v3.26.0-rc5~3^2~3) we had separate packaging jobs,
but they did not run in release packaging pipelines. Restore them, and
run them in both nightly and release packaging pipelines.
a44a2d2579 ci: Explicitly enable or disable RunCMake.AppleSilicon test in macos jobs
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10454
Enable it on `macos-arm64` jobs and disable it on `macos-x86_64` jobs.
Since the default detection pierces Rosetta, it cannot be used in CI
where we might build and test on different hosts.
The problem described in commit ec682ff22a (ci: Update to ROCm 6 HIP on
Fedora 41, 2024-12-02, v3.31.2~3^2) occurs here too. Move the CI work
directory to a path without spaces.
Issue: #25932
Commit messages in the CMake repo may have Git hashes that can trigger
false positives in the `typos` checker.
Revert commit ddebf4653d (ci: Do not check commit messages with 'typos'
due to false positives, 2025-02-07). Instead, copy the top-level config
file to a temporary location, add a configuration option to mark
10-hex-digit identifiers as always valid, and pass it to `typos` at the
commit checking phase.
Since commit c3777c1536 (ci: Extend spellcheck job with 'typos' tool,
2025-01-04) we check spelling with `typos` in addition to the
pre-existing check with `codespell`. Unlike `codespell`, `typos` can
find typos in combined identifiers, e.g., `PascalCase` or `snake_case`.
That works well for code, but in commit messages it can trigger on
"words" in the middle of commit hashes.
Brad King