| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
cd89d1c328 FindCUDAToolkit: Robust version checks when CUDA lang is not enabled
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Tested-by: Raul Tambre <raul@tambre.ee>
Merge-request: !5787
|
| |
| |
| |
| |
| |
| | |
Previously if you set `CMAKE_CUDA_COMPILER` but hadn't enabled
the CUDA language, FindCUDAToolkit would not correctly compute
the version information.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| | |
4ea6d3c3ae FindCUDAToolkit: Restore use of CUDA_PATH environment variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Raul Tambre <raul@tambre.ee>
Merge-request: !5761
|
| |
| |
| |
| |
| |
| |
| |
| | |
Refactoring in commit 7cc815a2a6 (CUDAToolkit: Detect CUDA SDK that
don't have nvcc, 2020-07-24, v3.19.0-rc1~366^2) accidentally broke
use of the `CUDA_PATH` environment variable.
Fixes: #21740
|
| |
| |
| |
| |
| |
| |
| | |
Invoke `nvcc -v` to find the real CUDA bin directory.
This is needed if `nvcc` is a symlink to `ccache` or `colornvcc`.
Fixes: #21177
|
|/
|
|
| |
Issue: #19715
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Previously when CMAKE_CROSSCOMPILING was ON we'd end up not setting the target
directory if the non-scattered one didn't exist.
Fix this by assuming a scattered installation if the target directory isn't set
after the crosscompiling logic.
This is the same fix as commit 2c0d5d01ee (CUDA: Support scattered
installations when crosscompiling with Clang, 2020-09-14).
|
|
|
|
|
|
|
|
| |
When a CUDA sdk doesn't have nvcc, defer to the existence of
a version.txt file. When we do this fall back we also reconstruct
the CUDA version via version.txt
Fixes #20643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/codespell-project/codespell#readme
The following command was used:
```
codespell -q6 --skip="\
.git,\
*.json,\
./Copyright.txt,\
./Help/command/foreach.rst,\
./Help/prop_test/REQUIRED_FILES.rst,\
./Help/variable/CTEST_COVERAGE_COMMAND.rst,\
./Modules/CMakeCheckCompilerFlagCommonPatterns.cmake,\
./Modules/CMakeRCInformation.cmake,\
./Modules/Internal/CPack/NSIS.template.in,\
./Modules/FindMatlab.cmake,\
./Modules/MatlabTestsRedirect.cmake,\
./Modules/Platform/Windows-Clang.cmake,\
./Modules/Platform/Windows-Intel-Fortran.cmake,\
./Modules/Platform/Windows-MSVC.cmake,\
./Source/CMakeVersion.cmake,\
./Source/cmConvertMSBuildXMLToJSON.py,\
./Source/cmCreateTestSourceList.cxx,\
./Source/cmGlobalVisualStudio10Generator.cxx,\
./Source/cmExportBuildFileGenerator.cxx,\
./Source/cmExportInstallAndroidMKGenerator.cxx,\
./Source/cmExportInstallFileGenerator.cxx,\
./Source/cmExportSet.cxx,\
./Source/cmExportTryCompileFileGenerator.cxx,\
./Source/cmFindPackageCommand.cxx,\
./Source/cmInstallCommand.cxx,\
./Source/cmGeneratorExpressionLexer.cxx,\
./Source/cmLocalVisualStudio7Generator.cxx,\
./Source/cmOrderDirectories.cxx,\
./Source/cmTarget.cxx,\
./Source/kwsys/*,\
./Source/QtDialog/CMakeSetupDialog.ui,\
./Source/CPack/WiX/cmWIXRichTextFormatWriter.cxx,\
./Source/CTest/cmParseCoberturaCoverage.h,\
./Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in,\
./Tests/RunCMake/CPack/tests/DMG_SLA/English.license.rtf,\
./Tests/RunCMake/CPack/tests/DMG_SLA/German.license.txt,\
./Tests/RunCMake/CPack/tests/DMG_SLA/German.menu.txt,\
./Tests/RunCMake/GoogleTest/xml_output.cpp,\
./Tests/RunCMake/Make/TargetMessages*,\
./Utilities/*,\
" \
-L "\
dependees,\
endwhile,\
fo,\
filetest,\
helpfull,\
nd,\
objext,\
stoll,\
supercedes,\
superceded,\
vas,\
varn,\
"
```
|
|
|
|
|
|
|
| |
Run the `Utilities/Sphinx/update_versions.py` script to add initial
markup to every top-level document and find module.
Issue: #19715
|
| |
|
|
|
|
|
| |
Similar to how we already do for Clang. Avoids a lot of redundant work in
FindCUDAToolkit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang isn't very good at finding the installed CUDA toolkit.
The upstream recommendation is that we should pass the toolkit explicitly.
Additionally:
* Avoids Clang having to search for the toolkit on every invocation.
* Allows the user to use a toolkit from a non-standard location by simply
setting CUDAToolkit_ROOT. The same way as with FindCUDAToolkit.
Clang wants the directory containing the device library and version.txt as the
toolkit path.
We thus pass the newly introduced CUDAToolkit_LIBRARY_ROOT as the toolkit path.
We save CUDAToolkit_ROOT_DIR and CUDAToolkit_LIBRARY_ROOT on Clang to have them
available in try_compile() and avoid unnecessary re-searching or a possibly
different installation being found in FindCUDAToolkit.
This however means that the selected toolkit can't be changed after the initial
language enablement.
We now determine CUDA compiler ID before doing actual detection, as we don't
want to spend time finding the CUDA toolkit for NVIDIA.
Implements #20754.
|
| |
|
|
|
|
|
| |
find_*() don't search if the result variable is already set.
Remove the if()s around such cases.
|
|
|
|
|
| |
We had a custom loop to sort in the natural order. Since CMake 3.18 this is
supported natively by CMake and simplifies the code significantly.
|
|
|
|
|
|
|
| |
We can avoid searching for this since CUDAToolkit_TARGET_DIR always contains
the include/ directory. But add a warning just in case.
Also apply this in CMakeDetermineCUDACompiler for Clang code.
|
|
|
|
|
|
|
|
|
| |
On scattered installations version.txt and nvvm are located at this location.
This may be useful to users and will allow us in the future to parse
version.txt instead of invoking nvcc to figure out the CUDA toolkit version.
We also add it to CMakeDetermineCUDACompiler in preparation for future use by
Clang code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A portion of FindCUDAToolkit was previously split in commit dc2eae1f
(FindCUDAToolkit: Factor out discovery code into a separate file, 2020-04-22)
out into Internal/CUDAToolkit to allow re-use of the code in
CMakeDetermineCUDACompiler for Clang support.
This has turned out to be a bad solution due to Clang requiring quite a bit of
special handling and special handling for NVCC leaking out from
Internal/CUDAToolkit into the Clang code using it.
Thus it seems better to re-unify this code and duplicate the parts of the code
necessary for Clang where it's required. This will help us get logic correct
for both NVCC and CUDA handling. We can still unify the common parts in the
future once the code has matured.
|
|
|
|
|
|
| |
This ended up after the searching after commit dc2eae1 (FindCUDAToolkit: Factor
out discovery code into a separate file, 2020-04-22).
Move it back to where it was and should be.
|
|
|
|
|
|
| |
This allows for re-use in other parts of the code, that require the CUDA
toolkit location, but can't or may not want to use the full
`FindCUDAToolkit`.
|
|\
| |
| |
| |
| |
| |
| | |
4f1e24efa0 FindCUDAToolkit searches stub location last
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4589
|
| |
| |
| |
| | |
Fixes #20252
|
|/
|
|
|
| |
This assumption doesn't hold for Clang.
When crosscompiling this causes X86 libraries to be used and thus linker errors.
|
|
|
|
| |
Fixes #20435
|
|
|
|
| |
Fixes: #20318
|
| |
|
|
|
|
|
| |
CUDAToolkit now adds the correct libraries that are required by the
static runtime.
|
|
|
|
|
|
|
|
|
| |
Update `_CUDAToolkit_find_and_add_import_lib` to create and add
dependencies to a target in one step that shared a single guard against
repeated definitions. Otherwise we were adding dependencies again on
every call.
Fixes: #20282
|
|
|
|
| |
Issue: #20282
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #20252
|
|
|
|
|
|
|
| |
CUDAToolkit now searches the correct targets folder based on
what platform we are cross-compiling for.
Fixes: #20232
|
|
|
|
|
|
| |
It is not a requirement to have shared|static consistent across your
CUDA libraries (e.g curand, nppc ) and your CUDA runtime library.
It is entirely allowable to use a static nppc and a shared runtime.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Refined the initial design of FindCUDAToolkit and improve it
by adding more library support, more toolkit information and
tests.
|
| |
|
|
|