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
