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

[James Bigler]

On Wed, Jan 6, 2010 at 10:41 PM, Brian Davis <bitminer at gmail.com> wrote:

>
>
> 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)
>
>
What kind of errors were you getting?

The FindCUDA.cmake script will definitely not work with anything less than
2.6.3.  There are script features that require that version, so I'm not sure
what CMake would do in that case.


>
> 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=
>
>
Again these are the the user supplied flags that will be applied to
*everyone*.  They don't take into consideration flags that were added on a
per configuration basis.  This is why I added the CUDA_VERBOSE_BUILD flag,
since each target can have their own unique set of flags.


>
>
>>
>>> 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.
>
>
Yes, it's hard to keep up with those guys, though there are some registry
keys and environment variables that I believe will persist (which is what I
try to make use of).


> 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)
>
>
First off, to be truthful, this is the first time I've become aware of these
extra options to find_package.  I'm not sure what they would do at the
moment, so setting CUDA_TOOLKIT_ROOT_DIR and CUDA_SDK_ROOT_DIR is the right
way to do this for now.