Since commit 0d0145138f (CUDA: Add abstraction for cuda runtime
selection, 2019-11-29, v3.17.0-rc1~83^2) we add CUDA runtime library
selection flags by default.
To maintain backwards compatibility the default CUDA runtime
library needs to be computed based on what libraries are found
on the initial compiler invocation. For example a toolchain
could establish initial flags that have all CUDA compilations
using the runtime version, and if we don't detect this we will
try to link to both the static and shared runtime.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #20708
When crosscompiling we pass the sysroot.
We need to try various architecture flags. Clang doesn't automatically
select one that works. First try the ones that are more likely to work
for modern installations:
* <=sm_50 is deprecated since CUDA 10.2, try sm_52 first for
future compatibility.
* <=sm_20 is removed since CUDA 9.0, try sm_30.
Otherwise fallback to Clang's current default. Currently that's `sm_20`,
the lowest it supports.
Separable compilation isn't supported yet.
Fixes: #16586
properties LINK_OPTIONS and INTERFACE_LINK_OPTIONS are propagated
to the device link step.
To control which options are selected for normal link and device link steps,
the $<DEVICE_LINK> and $<HOST_LINK> generator expressions can be used.
Fixes: #18265
Since commit d91b5a72cd (Ninja: Add support for CUDA nvcc response
files, 2019-05-30, v3.15.0-rc1~8^2) we use NVCC's `--options-file`
option to avoid long link command lines via a response file. However,
for non-device linking the host tools are used and the option does not
make sense. Update the logic to use `--options-file` only for device
linking. Linking with the host tools already has its own logic for
response files.
Fixes: #19954
Fixes#17559
Replace our hard-coded default of cudart=static with a first-class abstraction to select the runtime library from an enumeration of logical names.
Starting with CUDA 10.2 the nvcc compiler has gained support
to automatically forward unknown flags to the host compiler.
This behavior is highly desired as projcts that mix CUDA, C, C++
run into situation where flags such as `-pthread` which aren't
supported by nvcc, are being applied to all source files and
therefore break CUDA compilation.
Default to the same flag that is used for verbose link information, but
provide another internal platform information variable to use a
compilation-specific variant. Populate it for CUDA where we use a
different compiler for compilation and linking and therefore need
different flags.
Co-Author: Chuck Cranor <chuck@ece.cmu.edu>
Starting in CUDA 9 the default compilation mode is C++14, and you need
to explicitly enable C++98/03 mode.
While at it, document `14` among the values for `CUDA_STANDARD`. This
was accidentally left out of commit v3.9.0-rc1~118^2 (CUDA: Add support
for the C++14 standard flag, 2017-05-11).
Fix the default values of `CMAKE_CUDA_FLAGS[_<CONFIG>]` on Windows to
make the host compiler flags match those produced for C++ by the
`Platform/Windows-MSVC` module. This makes the flags consistent with
those used for C++.
Port Windows-specific compilation and linking rules over from the
`Platform/Windows-MSVC` module and adapt it for NVIDIA CUDA. On Windows
nvcc and its host compiler (MSVC) do not understand or use options like
`-fPIC` or `-std=`, so condition those out.
Since commit v3.7.0-rc1~392^2 (Honor CMAKE_<LANG>_FLAGS[_<CONFIG>]_INIT
set in toolchain files, 2016-07-05) our convention is to initialize
compiler flag variables via `string(APPEND)` rather than `set()`.
Fix the convention for `CMAKE_CUDA_FLAGS[_<CONFIG>]_INIT`.
