On Tue, Jan 5, 2010 at 12:23 PM, James Bigler <jamesbig...@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) >From FindCuda (with cmake now in my build tree so I can patch it): # Search in the CUDA_BIN_PATH first. find_path(CUDA_TOOLKIT_ROOT_DIR NAMES nvcc nvcc.exe PATHS ENV CUDA_BIN_PATH DOC "Toolkit location." NO_DEFAULT_PATH ) # Now search default paths find_path(CUDA_TOOLKIT_ROOT_DIR NAMES nvcc nvcc.exe PATHS /usr/local/bin /usr/local/cuda/bin DOC "Toolkit location." ) Following the advice from http://www.cmake.org/cmake/help/cmake-2-8-docs.html: The default search order is designed to be most-specific to least-specific for common use cases. Projects may override the order by simply calling the command multiple times and using the NO_* options: find_package(<package> PATHS paths... NO_DEFAULT_PATH) find_package(<package>) This is urrr... umm... hokey (calling multiple times). And I cannot seem to get it to work. so I set (ouput from my messages below in cmake output window) CUDA_TOOLKIT_DIR = C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/CUDA_Toolkit_2.2 NVIDIA_SDK_DIR = C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/NVIDIA_GPU_Computing_SDK_2.2 by doing: SET( PLATFORM_DIR platform/3rdParty/Win ) SET( PATCH_DIR platform/3rdParty/patch ) SET( THIRD_PARTY_PACKAGE_DIR source/cpp/lib/3rdParty/Win ) SET( TOOLS_DIR platform/tools ) SET( THIRD_PARTY_SRC_DIR 3rdParty/Win ) SET( APP_SRC_DIR source/cpp/app ) set( DO_LOCAL_CUDA YES ) if( DEFINED DO_LOCAL_CUDA ) SET( CUDA_VERSION 2.2 ) SET( NVIDIA_PACKAGE_DIR ${PLATFORM_DIR}/NVIDIA/GPU_Computing/CUDA_${CUDA_VERSION} ) SET( CUDA_TOOLKIT_DIR ${CMAKE_HOME_DIRECTORY}/${THIRD_PARTY_PACKAGE_DIR}/CUDA_Toolkit_${CUDA_VERSION} ) SET( NVIDIA_SDK_DIR ${CMAKE_HOME_DIRECTORY}/${THIRD_PARTY_PACKAGE_DIR}/NVIDIA_GPU_Computing_SDK_${CUDA_VERSION} ) MESSAGE( "CUDA_TOOLKIT_DIR = ${CUDA_TOOLKIT_DIR}") MESSAGE( "NVIDIA_SDK_DIR = ${NVIDIA_SDK_DIR}" ) unpack( ${NVIDIA_PACKAGE_DIR}/CUDA_Toolkit_${CUDA_VERSION}.zip ${THIRD_PARTY_PACKAGE_DIR} ) unpack( ${NVIDIA_PACKAGE_DIR}/NVIDIA_GPU_Computing_SDK_${CUDA_VERSION}.zip ${THIRD_PARTY_PACKAGE_DIR} ) set( CUDA_TOOLKIT_ROOT_DIR ${CUDA_TOOLKIT_DIR} CACHE STRING "" FORCE ) set( CUDA_SDK_ROOT_DIR ${NVIDIA_SDK_DIR} CACHE STRING "" FORCE ) find_package( cuda PATHS ${CUDA_TOOLKIT_DIR} ${NVIDIA_SDK_DIR} C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/CUDA_Toolkit_2.2 C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/NVIDIA_GPU_Computing_SDK_2.2 NO_DEFAULT_PATH) find_package( cuda ) endif() The line find_package( cuda PATHS ${CUDA_TOOLKIT_DIR} ${NVIDIA_SDK_DIR} C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/CUDA_Toolkit_2.2 C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/NVIDIA_GPU_Computing_SDK_2.2 NO_DEFAULT_PATH) Appears to have no effect, but: set( CUDA_TOOLKIT_ROOT_DIR ${CUDA_TOOLKIT_DIR} CACHE STRING "" FORCE ) set( CUDA_SDK_ROOT_DIR ${NVIDIA_SDK_DIR} CACHE STRING "" FORCE ) works,but I still get: cuda_DIR-NOTFOUND my project successfully builds with only SVN and VisualStudio as the only host dependency, everything else including cmake, boost,dcmtk, vtk, itk, gnuwin32 (unzip - why tar, bz2, and gz in cmake but no zip is anyone's guess, patch, and diff), cuda toolkit, cuda sdk are now all in the svn repo. Thanks for your help. -- Brian J. Davis
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake