[CMake] CUDA, CMAKE, and an attempt to build nbody

James Bigler jamesbigler at gmail.com
Tue Jan 5 13:23:41 EST 2010

> I ask my self two questions:
> 1) Why is CUDA_NVCC_FLAGS not set to some default build setting that would
> just work out of the box? - I get the answer to this question when I turn on
> CUDA_VERBOSE_BUILD_MODE - It is being set under the hood.

I guess I don't understand your question.  The CUDA_NVCC_FLAGS are the flags
used by all targets all the time.  Occasionally additional flags are added
(such as -fPIC on certain systems as well as other flags) that make it work
based on your individual project configuration.  It does work out of the box
for many applications.

> 2) There is a CUDA_TOOLKIT_INCLUDE, but no CUDA_SDK_INCLUDE (or _LIB)...
> why? (this would prevent ${CUDA_SDK_ROOT_DIR}/common/inc - see below)
As you found out the include directories for the CUDA SDK are not supported
by FindCUDA.  Those libraries and headers are designed to be used by the
SDK, and not particularly by external packages.  That doesn't prevent you
from doing so, but it was decided that because the CUDA SDK won't maintain
backward compatibility and is only designed for the SDK that external use
would not be supported by FindCUDA.  As a compromise I chose to have as a
bare minimum a path to the SDK be supported for those who wished to poke in
the SDK to find things such as libraries or header files.  There is
documentation in the help files and in the FindCUDA.cmake file as well as
examples of what to do with the CUDA_SDK_ROOT_DIR variable.

> Maybe these guys could answer question 2:
> James Bigler, NVIDIA Corp (nvidia.com - jbigler)

This is me.  Abe has a job at Apple, and doesn't have much time to maintain
this anymore.

> Abe Stephens, SCI Institute -- http://www.sci.utah.edu/~abe/FindCuda.html<http://www.sci.utah.edu/%7Eabe/FindCuda.html>
> A request here would be to seperate FindCUDA into :
> FindCUDA
> and
> and add include and lib dirs environment vars.

I welcome any volunteers to maintain a FindCUDASDK.  I don't plan on ever
supporting this.

> So I then add to my CMakeLists.txt file (I think in a vain attempt to make
> it work):
Yes, this in the right thing to do.

So I add:
> link_directories( ${CUDA_SDK_ROOT_DIR}/common/lib )
You might want to do what I suggest in FindCUDA.cmake and do the following
(copied from FindCUDA.cmake):

# Example of how to find a library in the CUDA_SDK_ROOT_DIR

# # cutil library is called cutil64 for 64 bit builds on windows.  We don't
# # to get these confused, so we are setting the name based on the word size
# # the build.

#   set(cuda_cutil_name cutil64)
#   set(cuda_cutil_name cutil32)

# find_library(CUDA_CUT_LIBRARY
#   NAMES cutil ${cuda_cutil_name}
#   # The new version of the sdk shows up in common/lib, but the old one is
in lib
#   PATH_SUFFIXES "common/lib" "lib"
#   DOC "Location of cutil library"
#   )
# # Now search system paths
# find_library(CUDA_CUT_LIBRARY NAMES cutil ${cuda_cutil_name} DOC "Location
of cutil library")
# mark_as_advanced(CUDA_CUT_LIBRARY)

Then do things like target_link_libraries(nbody ${CUDA_CUT_LIBRARIES})

You shouldn't need to create imported libraries through add_library and

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100105/3a7b312b/attachment.htm>

More information about the CMake mailing list