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>
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.
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.
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.
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.
- Use the correct path for the DNF cache.
- There is not much sense in having a DNF cache image separately when
the only `RUN` command is to install required packages.
- Do not waste time looking for pre-built images for Fedora.
Tell to `rvm` to always build from sources.
- No need to update startup files (in the intermediate image).
- Exclude useless (documentation) files from the final archive.
Michael Hirsch