Variables such as CMAKE_COMPILER_IS_GNUCC are documented as
obsolete/deprecated and ideally shouldn't be used in the code anymore
to have clearer compiler identifications.
In the past QCC compiler was identified as GNU and also had this
variable set to 1 (see policy CMP0047). Same still applies for LCC
compiler (see policy CMP0129).
Since commit d74210a8bd (CMP0017: Remove support for OLD behavior,
2024-11-17) we can rely on CMP0017's NEW behavior unconditionally.
Calling `include(FindPackageHandleStandardArgs)` in a builtin module
will always get the builtin `FindPackageHandleStandardArgs`.
Covers almost all blocks containing actual code, except:
* Parsed-literal blocks can't be highlighted, including many command
summaries and substitution-heavy docs like find_... commands.
This is a Sphinx limitation.
* Code with errors, like CMP0049, DEPLOYMENT_ADDITIONAL_FILES,
DEPLOYMENT_REMOTE_DIRECTORY, @PACKAGE_INIT@ substitution in the
tutorial, bracket arguments/comments in cmake-language.7 and
cmake-developer.7.
* FindQt4 module, which needs reformatting.
FindCUDA's custom commands invoke `nvcc`, which invokes `cl`. Under VS
this is done without a `/FS` flag, so `.pdb` generation races if we
use `BuildInParallel`. The FindCUDA module has already been removed by
policy CMP0146 after being deprecated since CMake 3.10, so it is
simplest to just disallow this combination of features.
Issue: #24576
The `FindCUDA` module has been deprecated since CMake 3.10.
Add a policy to pretend it doesn't exist in order to encourage
projects to port away from it.
Extend the change from commit 1d9f2f9714 (FindCUDA: Do not search for
the deprecated nppicom when CUDA >= 11, 2020-06-22, v3.18.0-rc3~14^2)
to also not use the `CUDA_nppicom_LIBRARY` variable.
Issue: #20845
CUDA_TOOLKIT_TARGET_DIR doesn't always exist in the cache or defined by the user
previous to using FindCUDA. In this case it will always reset the variables
making it impossible to manually change or set them. This can be fixed by
checking to see if the variable is defined before checking against the
previously used version stored in CUDA_TOOLKIT_TARGET_DIR_INTERNAL.
Simplified the text regarding adding sources to be more general as there's also
target_sources().
Improved the wording for FindCUDAToolkit to be more explicit of its usecase and
avoid using "superseded" since the common usecase of FindCUDA was superseded by
the language support.
Wording suggestions incopropated from discussion on #22203.
FindCUDA is still widely used, but has been superseded by the much more robust
native language support. However the deprecation hasn't been noticed well
enough and real-world experience shows there's still new code written to use
it.
Change this particular notice to a warning to get a hard to miss red box.
We lose the semantic meaning, but we don't want to make all notices like this.
If there are similar cases in the future requiring it would be worth adding a
custom variant of the deprecated directive.
Fixes#22203.
The original regular expression was greedy and would match any
environment variable ending with `TOP` (like `DESKTOP`). This is an
issue on windows where `nvcc -v` would output all environment variables
before the compiler's verbose output.
To resolve this issue we use a tighter match algorithm that looks
for `#$ TOP=` instead of `TOP=`.
Fixes: #22158
Since commit fb2afef620 (CUDA: Support nvcc symlinking to ccache,
2021-01-07) and commit 3cef91a321 (CUDA: Always extract CUDA Toolkit
root from nvcc verbose output, 2021-02-03) we always run the command
`nvcc -v __cmake_determine_cuda` to look for the toolkit root in its
stderr. On Windows, that command may print to stdout instead, so
capture that as well.
Fixes#21750, #21763
Given that NVCC can be provided by multiple different sources (NVIDIA HPC SDK, CUDA Toolkit, distro)
each of which has a different layout, we need to extract the CUDA toolkit root from the compiler
itself, allowing us to support numerious different scattered toolkit layouts.
The NVIDIA HPC SDK specifically ships two copies of nvcc one in
`compilers/bin/` and one in `cuda/bin`. Thus when using
`compilers/bin/nvcc` the Toolkit root logic fails.
* Split large literal blocks into definitions lists.
* Add section headers.
* Add links to standard commands and variables.
* Use inline literals liberally.
* Enable code highlighting in literal blocks.
* Format command signatures according to modern conventions.
This fixes the following two issues with the CUDA support on QNX:
* cuda target name is not derived correctly (should be `aarch64-qnx`).
* linking `cudart` must not be linked against `rt`, `dl`, `pthread`.
This enables to use cmake's native cuda support on QNX.
Fixes: #21381
In commit 46371132b3 (FindCUDA: CUDA_LIBRARIES doesn't contain raw
`-pthread`, 2019-11-11, v3.17.0-rc1~455^2) we introduced use of the
`Threads::Threads` target, but we do not `find_package(Threads)` on all
platforms. Use the target only if it exists.
2d0100fac7 replace remove and remove_directory with rm in tests
5239fc5c75 cmake -E: Add rm with improved semantics over remove and remove_directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3949
If a person tried to pass `CUDA_LIBRARIES` to nvcc compiler it could
fail as it might have `-pthread` which nvcc doesn't support. Instead
we now use the `Threads::Threads` so that nvcc gets the correct
`-Xcompiler -pthread` flag.
Revert commit 067ee518f7 (FindCUDA: Use find_program instead of
find_path to find nvcc, 2019-10-31). It causes `CUDA_TOOLKIT_ROOT_DIR`
to contain the path to nvcc rather than the toolkit directory.
We do not need to support IRIX anymore, so drop relevant parts. In
particular, the `CMAKE_THREAD_PREFER_PTHREAD` is frequently confused
with `THREADS_PREFER_PTHREAD_FLAG`.
Also remove references to the IRIX-specific options and results
from other modules and tests.
Revert commit v3.11.0-rc1~274^2 (FindCUDA: Add cublas device library to
separable compilation, 2017-11-03). It breaks targets that do not link
to cublas. Another solution will be needed to solve the original
problem in a more compatible way.
Fixes: #17965
