3ff777de12 CUDA: Update CUDA tests to handle CUDA 13 deprecations
bbf732525a CUDA: Add CUDA 13.0 support to 'all' and 'all-major' architecture tables
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11015
3ff777de12 CUDA: Update CUDA tests to handle CUDA 13 deprecations
bbf732525a CUDA: Add CUDA 13.0 support to 'all' and 'all-major' architecture tables
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !11015
POSIX specifies that two leading slashes have implementation-defined
interpretation, so CMake 3.31 and below did not normalize away leading
double slashes. However, most implementations simply treat a leading
`//` as just `/`, so CMake 4.0 now normalizes them away when they do not
correspond to a network path on Windows.
This change exposed that we were not normalizing `CMAKE_TOOLCHAIN_FILE`
before passing its value to `include()` the first time if it was not
passed with the `FILEPATH` or `PATH` cache entry type. Fix that.
Fixes: #27010
Upcoming versions of nvcc are adding support for `SYSTEM_INCLUDES`
which contain includes that are implicitly used with `-isystem`
instead of `-I`.
Support of this is needed in CMake as some CUDA Toolkit releases will
start to have a different include directory layout and using only the
output from `INCLUDES` will be insufficient to find all headers.
Clang before 20.1 does not recognize sm_100 and newer. Revise:
* commit b2251e0deb (CUDA/Clang: Update architectures supported by
CUDA 12.8, 2025-02-04, v4.0.2~4^2~1^2)
* commit a1b4c30f24 (CUDA: Add CUDA 12.9 new architectures and family
syntax, 2025-04-21, v4.0.2~3^2^2)
41a4a32135 FindPython: Avoid implicit link library on Windows
811f00f9ad FindPython: rely on ABIFLAGS on Windows for ABI profile
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10800
Starting with version 3.14, on Windows, by specifying macro Py_NO_LINK_LIB,
the python library is no longer implicitly specified at the link step.
Fixes: #26756
As outlined in the CUDA 12.9 release notes sm_5X, sm_6X, and sm_70
are being removed in CUDA 13:
> Maxwell, Pascal, and Volta architectures are now feature-complete with
> no further enhancements planned. While CUDA Toolkit 12.x series will
> continue to support building applications for these architectures,
> offline compilation and library support will be removed in the next
> major CUDA Toolkit version release.
bf1bb62e74 macOS: Restore support for LLVM/Clang without explicit CMAKE_OSX_SYSROOT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10734
a1b4c30f24 CUDA: Add CUDA 12.9 new architectures and family syntax
b2251e0deb CUDA/Clang: Update architectures supported by CUDA 12.8
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10738
In commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to compilers
by default, 2024-11-06, v4.0.0-rc1~511^2) we broke support for using
upstream LLVM/Clang to build for macOS because the compiler has no
default sysroot. Handle empty `CMAKE_OSX_SYSROOT` with LLVM/Clang by
falling back to the macOS SDK reported by `xcrun --show-sdk-path` .
Fixes: #26863
LLVM/Clang 20, when invoked as `clang++ -E -c ...`, now warns:
warning: argument unused during compilation: '-c'
Drop the unnecessary `-c` flag. Also add a `-w` flag to suppress
warnings so their text is not parsed as predefines.
This makes the default CUDA architecture consistent across compilers,
and makes it more likely that the resulting binary will run on the
user's hardware.
This also makes hardware requirements for CI builds more consistent.
See commit 4f2178c4a8 (ci: add tags to tie CUDA jobs to runners with
hardware supporting them, 2025-04-21).
Since commit 7b19531291 (macOS: Do not pass any SDK/-isysroot to
compilers by default, 2024-11-06, v4.0.0-rc1~511^2) our default
invocation of compilers targeting macOS no longer passes `-isysroot`.
Without that, Xcode's compilers search `-L/usr/local/lib` by default
even though the macOS dynamic loader does not. Since `/usr/local/lib`
is not a fully-implemented implicit link directory, exclude it from our
detected `CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES` so that our generators
do not suppress `RPATH` entries for dependencies in that directory.
Fixes: #26867
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
In commit f69b9b7305 (CUDAToolkit: Restore ability to find cupti
headers, 2023-12-08, v3.28.1~8^2) we did not update the CUPTI library
searches to add the extra search path needed for certain install layouts
(only the header search path). Add the additional library search paths.
Fixes: #26770
Issue: #25484
Commit 1a8e43d57d (FindPackageHandleStandardArgs: Clarify the FOUND_VAR
option, 2024-12-31, v4.0.0-rc1~247^2) simplified the
`<PackageName>_FOUND` and `<PACKAGENAME>_FOUND` variables one step
further but missed that this specific module sets the `QT4_FOUND`
variable also for the case where `find_package_handle_standard_args()`
isn't called (for example, when the found package is Qt3 or Qt5 and
later). Restore the `set()` call in case `QT4_FOUND` is used in the
code.
