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
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
