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

[Brian Davis]

On Tue, Jan 5, 2010 at 12:23 PM, James Bigler <jamesbigler at gmail.com> wrote:

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

I am trying to remember what the issue here was.  I think it was that I
could not see all the build settings AND (this is important) at the time I
was using the dcmtk library and adding it to my project using
add_subdirectroy( whereever/dcmtk ).  DCMTK appears to force cmake backwards
compatibility version which if used with FindCuda messes up the build.  At
least this is what I was experiencing. I am patching dcmtk with:

diff -rupN dcmtk-3.5.4-original/CMakeLists.txt dcmtk-3.5.4/CMakeLists.txt
--- dcmtk-3.5.4-original/CMakeLists.txt    2010-01-04 10:05:14.426524200
-0600
+++ dcmtk-3.5.4/CMakeLists.txt    2010-01-02 10:38:17.792807400 -0600
@@ -8,9 +8,9 @@ ENDIF(NOT WIN32)

 # check required version of CMake
 CMAKE_MINIMUM_REQUIRED(VERSION 2.0)
-IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
-  SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of
CMake when this project was released." FORCE)
-ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
+#IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)
+#  SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of
CMake when this project was released." FORCE)
+#ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)

 # default build type
 SET(CMAKE_BUILD_TYPE RELEASE)


This question turned out as I wrote the email to be a rhetorical question /
documentation of my experience.  CUDA_NVCC_FLAGS does not appear in the
CMakeCache.txt (and I was expecting it to).  CUDA_NVCC_FLAGS and friends in
CMakeCache.txt:


//Semi-colon delimit multiple arguments.
CUDA_NVCC_FLAGS:STRING=

//Semi-colon delimit multiple arguments.
CUDA_NVCC_FLAGS_DEBUG:STRING=

//Semi-colon delimit multiple arguments.
CUDA_NVCC_FLAGS_MINSIZEREL:STRING=

//Semi-colon delimit multiple arguments.
CUDA_NVCC_FLAGS_RELEASE:STRING=

//Semi-colon delimit multiple arguments.
CUDA_NVCC_FLAGS_RELWITHDEBINFO:STRING=




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

Yes it looks as though from 2.2 to 2.3 and 3.0_Beta_1 they (NVIDIA) added a
/C/ directory in the sdk and moved  bin, common, etc there.  If I could only
create a ClairVoyantFindCUDA to know of future changes such as these.

So lets say that I take CMake compresed as a zip file
cmake-2.8.0-win32-x86.zip and make it a part of my repository tree.  Not
installed in Windows using installer in an attempt to make the build
computer not dependent on anything except the source control tool
(subversion) and Visual Studio.  I also take the CUDA SDK and CUDA Toolkit
and put it in my tree after installing on build computer and ziping contents
at C:\cuda and C:\Nvidia Corporation\.  Then I uninstall the sdk and
toolkit.  After preforming a clean install on a machine and diffing the
directory before and after. This *might* be possible with the follwing
exception:

01/06/2010  11:53 AM           151,552 nvRegDev.dll

So I was also experiencing, just today, that I am unable to get FindCUDA
working with PATHS specified or HINTS (if I am using it correctly):

find_package(<package> PATHS paths... NO_DEFAULT_PATH)