It is possible to have trailing ( and maybe leading ) newlines in a test name. This causes problems with ctest
features like `tests-from-file` since they will never
be an exact match.
So now we sanitize names by removing these newlines
The original addition of CMD_INSTALL_ABSOLUTE_DIR by commit
39a56136a3 (Diagnostic: Add warn or error on absolute install paths,
2026-03-25) didn't cover all install signatures. Add checks to cover
those install types that weren't covered by the original commit.
`LINK_LIBRARIES` entries guarded by `$<COMPILE_ONLY:...>` are not
linked, but must participate in target ordering so files generated by
compile-only dependencies, like headers, are available before
compilation.
Fixes: #27792
Add `-Winstall-absolute-destination` diagnostic to warn or
error when an install command has an absolute destination.
This allow projects to enforce the best practice of not allowing
absolute install DESTINATIONS.
The cmPkgConfigEnv* of cmPkgConfigResult would point
to a deleted stack copy.
This can causes issues when cmPkgConfigResult::Libs()
is called and we have to fall back to querying the
env.
On windows when you run `nvcc -v` all the env variables will
be printed before nvcc verbose output. This allows us to handle
the cases where env variable exists with the same name as a magic
nvcc keyword we parse
In commit 9d44a77454 (find_*: Explicitly normalize found paths as they
exist on disk, 2024-10-17, v4.0.0-rc1~597^2~1), we removed path
normalization from the internal `cmSearchPath::AddPathInternal` helper.
Most call sites were updated to normalize input paths first, but search
paths derived from `<PackageName>_ROOT` CMake variables are no longer
normalized. Instead we normalize the path to the file found after
searching.
When `find_package` "config" mode considers a candidate CMake package
configuration file, normalize its path before loading the adjacent
package version file so that the latter is loaded by absolute path.
Otherwise `cmMakefile::ReadDependentFile` interprets a relative path
with respect to the current source directory rather than the current
working directory.
Fixes: #27279
In commit 9d44a77454 (find_*: Explicitly normalize found paths as they
exist on disk, 2024-10-17, v4.0.0-rc1~597^2~1), we removed path
normalization from the internal `cmSearchPath::AddPathInternal` helper.
Most call sites were updated to normalize input paths first, but search
paths derived from `<PackageName>_ROOT` CMake variables are no longer
normalized. Instead we normalize the path to the file found after
searching.
When `find_package` "config" mode considers a candidate CMake package
configuration file, normalize its path before loading the adjacent
package version file so that the latter is loaded by absolute path.
Otherwise `cmMakefile::ReadDependentFile` interprets a relative path
with respect to the current source directory rather than the current
working directory.
Fixes: #27279
Starting in CUDA 12.9 the `nvToolsExt` library is no longer provided.
C and C++ projects should switch over to `nvtx3`.
Projects that previously used `nvToolsExt` with Fortran, can now use the
new `CUDA::nvtx3_interop` target for the same functionality with the new
NVTX v3 API.
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.
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.
CUDA 12.8 deprecates architectures below 75. Presumably a future
version will remove it. Prepare infrastructure to avoid relying on
hard-coded arch 50 in this test.
This extends commit 63a5460faf (ci: Tell CudaOnly.Architecture test what
specific architecture to use, 2025-04-21).
Previously we didn't properly exclude $<COMPILE_ONLY:OBJECT lib>
from the right hand side of `target_link_libraries`.
Fix the update that commit 73337cb383 (LINK_LIBRARIES: Evaluate
separately for linking and usage requirements, 2022-03-22,
v3.24.0-rc1~404^2~2) made to `AddObjectEntries`.
Fixes: #26642
This ensures that a user after providing custom flags
will first see that attempt. Previously the compiler attempt with the user flags could have been lost due to
console log buffer / scrolling support
The `BUILD_TESTING` variable is referenced in `add_test` and
`enable_testing`. It should be documented as it controls the
behavior tests working when projects use `include(CTest)`.
The default behavior of bin2c is to create binary arrays that have no
null termination. So to use it as a C array we need to explicitly tell
it to create valid null terminated strings.
This will safely allow us to run PTX tests across all CUDA drivers.
The dependency on nvJitLink was due to misunderstanding how runtime compiled code that uses
LTO is used. It doesn't require nvrtc to have a dependency on nvJitLink, just the caller.
Depending on nvrtc-builtins breaks CUDA enhanced compatibility across
minor versions. The static version of nvrtc continues to need the
dependency due to undefined symbols
The nvrtc-builtins and nvptxcompiler projects don't required linking
to the cuda driver. We previously did this due to reading the
upstream documentation incorrectly.
This was missed in commit ca5a300d7f (add_test: Honor
CROSSCOMPILING_EMULATOR only when cross-compiling, 2023-11-02) when it
slipped from the 3.28 release.
Instead of stating that the default is the native compilers,
say we will use the compilers from the preset. This makes it
more clear that the preset is working as expected.
Fixes#25484
PR !8835 failed to update the CUPTI header searches to use the
new internal FindCUDAToolkit search variables. This caused the
CUDA::cupti target to always not exist.
Improves the handling of CUDA layouts where we have multiple include
and library directories listed in the output of `nvcc -v`. This
updates both when the CUDA language is enabled or not.
Fixes: #24915
Due to an oversight in cmLinkLineDeviceComputer object
files did not get propagate to the device linking phase
when given via the `$<TARGET_OBJECTS>` generator expression.
When given objects via `target_link_libraries(consumer PRIVATE producer)` the VisualStudio solution adds the objects
under as `<Object>` entries in the solution.
This works for host side linking but isn't handled by
the cuda msbuild extensions. So to work around this we
manually add the objects as additional link items.
Without `CudaLink` fields, MSBuild tries to perform a device link step
for object libraries with CUDA_SEPARABLE_COMPILATION on them even when
not needed. This commonly was encountered when generating PTX or
OPTIX-IR output.
Robert Maynard
