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>
There is the global CMAKE_DL_LIBS setting which can be used instead. There are
even platforms where this is either empty because those functions are part of
the libc or is called entirely different, so this code wouldn't work reliable
anyway.
The handling of multilevel dependencies has been fixed in Visual Studio 2013.
The work around used for VS 2010 and VS 2012 does not work for VS 2013 any more.
Switch to normal object build rules for VS 2013 and newer.
Otherwise using a "cc -> ccache" or similar symlink as the compiler
causes FindCUDA to select ccache as the host compiler. Update the logic
added by commit v3.1.0-rc1~354^2 (FindCUDA: Fix OSX Clang & no C
language enabled, 2014-06-12) to apply only in the specific case it is
needed.
During compilation of the intermediate link file, the output directory
may not be present in Visual Studio builds. This fix makes sure the
output directory exists before generating the output file.
Suggested-by: Irwin Zaid
I was previously appending to nvcc_flags inside the file loop. This
caused the flag to be appended multiple times which freaks out nvcc.
Now the flag is specifically handled per file.
A previously undocumented feature allowed overriding the format
specified to CUDA_WRAP_SRCS with a source file property called
CUDA_SOURCE_PROPERTY_FORMAT. I added documentation for this feature as
well as added the ability to let nvcc compile any file regardless of
type if this property was found.
In addition, I also fixed a couple of bugs with the calls to
_cuda_get_important_host_flags that weren't garding the arguments with
"" to prevent empty values from causing errors.
If the host flags contain a c++11 flag (at least for gcc), then we can't
automatically propagate to nvcc it using -Xcompiler. This is because
nvcc can't use any C++ only flags. Instead we find this flag and add it
to nvcc's flags (it has a special flag for dealing with c++11 code) and
remove it from the host flags.
Co-Author: Guillermo Marcus <gmarcus@nvidia.com>
Beginning in CUDA 5.5 a static version of the cuda runtime library
became available. Since nvcc defaults to using this library over the
shared version, FindCUDA will also default to using this version. There
are many advantages to using the static version (most importantly to
avoid conflicts with multiple versions when building a CUDA based
library). Offer a CUDA_USE_STATIC_CUDA_RUNTIME option to control
this behavior.
CMAKE_SYSTEM_PROCESSOR is not guaranteed to be defined (per
http://www.cmake.org/Wiki/CMake_Cross_Compiling), and when cross
compiling where it happens to be undefined, this module was broken.
Reviewed-by: Rolf Eike Beer <eike@sf-mail.de>
Previously only the CMAKE_{C,CXX}_FLAGS_<CONFIG> flags were inspected
for relevant flags when compiling the intermediate link file. We need
to also consider the configuration agnostic flags, CMAKE_{C,CXX}_FLAGS
as well.
When setting default CUDA_HOST_COMPILER we must dereference CMAKE_C_COMPILER,
i.e. /usr/bin/clang should be used instead /usr/bin/cc which is symlink.
Otherwise CUDA thinks it is GCC and issues -dumpspecs which is unknown option
to Clang.
Also in case neither CMAKE_C_COMPILER is defined (project does not use C
language) nor CUDA_HOST_COMPILER is specified manually we should skip -ccbin
and let nvcc use its own default C compiler.
Some modules change CMake minimum required version when they are
included. For example:
cmake_minimum_required(VERSION 2.8.12)
message("${CMAKE_MINIMUM_REQUIRED_VERSION}")
include(CheckTypeSize)
message("${CMAKE_MINIMUM_REQUIRED_VERSION}")
will produce the following output:
2.8.12
2.6
This patch ensures that when you include a CMake module the minimum
required version and the policies set are left unchanged.
Fixes Issue #14864
Previously when linking the intermediate link file for separable compilation
the CUDA_NVCC_FLAGS* were not used. This caused tremendous confusion when
using this feature, and I consider it to be a bug. This change should fix
this.
* added CUDA_TOOLKIT_TARGET_DIR CMake variable that used
to locate headers and libraries for target platform
* added CUDA_TARGET_CPU_ARCH which is set to ARM for
arm cross-compilation and is used to add
--target-cpu-architecture NVCC flag
CMake's intended interface for linking to explicit object files (marked
with EXTERNAL_OBJECT) is that only those listed as target sources should
be linked. Drop FindCUDA's attempt to hide the .obj files from VS IDE
project files, which depends on VS-version-specific behavior of linking
custom command outputs that happen to be named "*.obj". CMake puts
external object files in a dedicated source group anyway.
Ubuntu install the CUDA libraries into a location that is different
than the default location provided by the NVidia installer. So we
teach the FindCUDA package to also find the Ubuntu install location.
As of CMake 2.8.8, the INCLUDE_DIRECTORIES() command does
not de-duplicate entries. Failure to do so can lead to an extremely
long and repetitive list of -I entries on the command line.
make CUDA_COMPUTE_BUILD_PATH use a relative path to the current
binary directory instead of the current source directory if the source
file considered is in the current binary directory. This is done to
shorten the paths given to the compiler.
Use normal custom command dependencies by default. Use the PRE_LINK
approach only to work around what seems to be a bug in msbuild handling
of custom build rules that chain together.
Felix Geyer
Chuck Atkins
Boris Fomitchev
James Sharpe
Felix Geyer
Brad King
Alexander Szakaly
Rolf Eike Beer
Dominic Meiser
Bill Hoffman
James Bigler
Mark Abraham
Andrew Seidl
Clinton Stimpson
Adam Strzelecki
Daniele E. Domenichelli
Tobias Zirr
Ben Boeckel
Vladislav Vinogradov
Kitware Robot
Robert Maynard
Marcel Loose
Mathias Gaunard