When `CMAKE_C_COMPILER` is `clcache`, pass plain `cl` as the host
compiler to `nvcc`. Otherwise, `nvcc` does not accept it.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
This is useful if, for example, you want ccache to be used
for nvcc. With the current behavior, cmake always picks up
/usr/local/cuda/bin/nvcc, even if there is a ccache nvcc
stub in the PATH. Allowing for CUDA_NVCC_EXECUTABLE lets
us work around the problem.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Changes in commit 48f7e2d300 (Unhardcode the CMAKE_CONFIGURATION_TYPES
values, 2017-11-27) accidentally left `CUDA_configuration_types`
undefined, but this is used in a few places to handle per-config flags.
Restore it.
Fixes: #17671
This removes duplicated code for per-config variable initialization by
providing a `cmake_initialize_per_config_variable(<PREFIX> <DOCSTRING>)`
function.
This function initializes a `<PREFIX>` cache variable from `<PREFIX>_INIT`
and unless the `CMAKE_NOT_USING_CONFIG_FLAGS` variable is defined, does
the same with `<PREFIX>_<CONFIG>` from `<PREFIX>_<CONFIG>_INIT` for every
`<CONFIG>` in `CMAKE_CONFIGURATION_TYPES` for multi-config generators or
`CMAKE_BUILD_TYPE` for single-config generators.
3c413e2a GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in Modules
c267ea1c GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in Tests
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1627
Some modules assume that `/usr` and `/usr/local` are the only
`CMAKE_PREFIX_PATH` entries and explicitly enumerate all paths instead
of using `PATH_SUFFIXES` and relying on the dynamic set of prefix paths.
This commit attempts to rectify that behavior.
Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
Since commit v3.0.0-rc6~3^2 (FindCUDA: Use CUDA_NVCC_FLAGS* for
separable compilation, 2014-05-18), using the feature for one
configuration results in empty-string ("") arguments on the command line
for other configurations. This is because the generator expression for
a non-matching configuration evaluates to an empty string but does not
remove the argument. Use `COMMAND_EXPAND_LISTS` to remove the empty
arguments from the custom command after genex evaluation.
Fixes: #16411
CMake does not define the `find_host_program` command we've been using
in the cross-compiling code path. It was provided by a widely used
Android toolchain file. For compatibility, continue to use
`find_host_program` if available, but otherwise use just `find_program`.
Fixes: #16509
This adds the option CUDA_LINK_LIBRARIES_KEYWORD which can be set to PRIVATE,
PUBLIC, or INTERFACE or left empty (the default) to use the old form of
target_link_libraries internally in FindCUDA macros.
Fixes: #16772
Added a counter as a directory property that gets incremented every time one
of the cuda_compile* macros is called. The value of this counter is then added
to the phony target name passed to CUDA_WRAP_SRCS. This ensures that every call
to one of these macros has its own unique intermediate output directory.
The macros CUDA_COMPILE, CUDA_COMPILE_PTX, CUDA_COMPILE_FATBIN, and
CUDA_COMPILE_CUBIN were broken by commit 7ded655 (FindCUDA: Take NVCC
include directories from target properties, 2016-08-16). This bug is
due to the fact that all of these macros call CUDA_WRAP_SRCS with a
target name that's not an actual target, causing the new generator
expressions to fail.
Fix the bug by changing these macros to pass "PHONY" to CUDA_WRAP_SRCS.
Now, when CUDA_WRAP_SRCS sees "PHONY", it falls back to the old behavior
of populating the include directories and compile definitions from
directory properties, instead of using target generator expressions.
Fixes issue where include directories specified on the target are
not passed on to NVCC. This includes both target_include_directories()
as well as include directories added by dependency chaining.
Closes: #14201
Commit 7229ae72 (FindCUDA: Refactor Android(Tegra) support, 2016-04-19)
changed the logic to only add librt to the link line for CUDA versions
6.5 and older. However, newer versions of CUDA still require librt.
Fix bug introduced by commit 7229ae72 (FindCUDA: Refactor Android(Tegra)
support, 2016-04-19). `CUDA_USE_STATIC_CUDA_RUNTIME` should be enabled
by default if `cudart_static` is available, and silently disabled if
it is not.
When enabling the CUDA static runtime, the current module always uses
the shared runtime in the REQUIRED_VARS check. This change should
select the correct runtime to be checked for as required based on the
CUDA_USE_STATIC_CUDA_RUNTIME option.
Fixes#16096
Follow the configure_file by a file(GENERATE) so the resulting cmake
scripts used by FindCUDA for wrapping nvcc calls can now support
generator expressions in the CUDA_NVCC_FLAGS variable.
Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly. Fix the
separate compilation code path to not add its own quoting when the
VERBATIM option will be used.
Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly. However,
this breaks the special `$(VCInstallDir)` placeholder used with Visual
Studio generators. Since we do not support preservation of such
placeholders with VERBATIM (see issue #15001) we must fall back to not
using VERBATIM when the placeholder is used.
A better fix would be to stop using `$(VCInstallDir)` and use the value
of `CMAKE_${CUDA_C_OR_CXX}_COMPILER` instead, but that will require
additional semantic and documentation changes. For now simply fix the
regression with the above approach.
Reported-by: Stephen Sorley <Stephen.Sorley@jhuapl.edu>
Add `VERBATIM` to all `add_custom_command` calls so that CMake will
escape arguments properly even when special characters such as "()" are
present.
Suggested-by: Nils Gladitz <nilsgladitz@gmail.com>
