<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br>What kind of errors were you getting?<br><br></div></div></blockquote>
<div class="gmail_quote"><div><br>I would point to a URL on GMane for the thread titled "Build only what you need in third party libs" , but it looks as though Gmane does not have all the postings. I was getting bounces back from CMake mailing list due to size of email.<br>
<br>Here is an excerpt from my local copy of the email:<br><br>I have the following line in one of my CMakeLists.txt files which I have traced the issue down to. <br><div class="im"><br>add_subdirectory( ${THIRD_PARTY_SRC_DIR}/dcmtk-3.5.4 ./dcmtk-3.5.4 )<br>
<br></div>When I include this line the nbody app fails to build. When I remove it the NBody app compiles.<br>
<br>The link error created when dcmtk is included in the project is:<br><br>1>Linking...<br>1>bodysystemcuda.obj
: error LNK2019: unresolved external symbol allocateNBodyArrays
referenced in function "protected: virtual void __cdecl
BodySystemCUDA::_initialize(<div id=":1qa" class="ii gt">int)" (?_initialize@BodySystemCUDA@@MEAAXH@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
registerGLBufferObject referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_initialize(int)" (?_initialize@BodySystemCUDA@@MEAAXH@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
unregisterGLBufferObject referenced in function "protected: virtual
void __cdecl BodySystemCUDA::_finalize(void)" (?_finalize@BodySystemCUDA@@MEAAXXZ)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
deleteNBodyArrays referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_finalize(void)" (?_finalize@BodySystemCUDA@@MEAAXXZ)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
setDeviceSoftening referenced in function "public: virtual void __cdecl
BodySystemCUDA::setSoftening(float)" (?setSoftening@BodySystemCUDA@@UEAAXM@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
integrateNbodySystem referenced in function "public: virtual void
__cdecl BodySystemCUDA::update(float)" (?update@BodySystemCUDA@@UEAAXM@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayFromDevice referenced in function "public: virtual float *
__cdecl BodySystemCUDA::getArray(enum BodySystem::BodyArray)"
(?getArray@BodySystemCUDA@@UEAAPEAMW4BodyArray@BodySystem@@@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayToDevice referenced in function "public: virtual void __cdecl
BodySystemCUDA::setArray(enum BodySystem::BodyArray,float const *)"
(?setArray@BodySystemCUDA@@UEAAXW4BodyArray@BodySystem@@PEBM@Z)<br>
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
threadSync referenced in function "public: virtual void __cdecl
BodySystemCUDA::synchronizeThreads(void)const " (?synchronizeThreads@BodySystemCUDA@@UEBAXXZ)<br>
1>C:\projects\NIH2009\source\branches\<span class="il">brian</span>\build\Windows-6.1\ouput\bin\Debug\nbody.exe : fatal error LNK1120: 9 unresolved externals<br>1>Build log was saved at "file://c:\projects\NIH2009\source\branches\<span class="il">brian</span>\build\dvip4-Win64-broken\cpp_source\app\nbody\nbody.dir\Debug\BuildLog.htm"<br>
1>nbody - 10 error(s), 0 warning(s)<br><br>Which
is a linker error where extern "C" files cannot be found. The
inclusion of a third party lib affects the project globally. Now
conversations above imply that CMake was never designed for this type
of use case. I have already had to change boost cmake build and will
be submitting my patch to that mailing list. It appears as though now
dcmtk does not play nice either. There are differences in the files...
some I expect and others I did not.<br>
</div><br>... it continues on and shows a diff of the project files that cmake generates, which I will not post here for fear of the 40kb limit:<br><br><br>I notice a change from:<br><br>< set(source_file "C:/projects/NIH2009/source/<div id=":1qa" class="ii gt">
branches/<span class="il">brian</span>/source/cpp/app/testing/cudaTests/nbody/src/<a href="http://bodysystemcuda.cu/" target="_blank">bodysystemcuda.cu</a>")<br>
<br>To:<br><br>> set(source_file "C:/projects/NIH2009/source/branches/<span class="il">brian</span>/source/cpp/app/testing/cudaTests/nbody/src/<a href="http://nbody_kernel.cu/" target="_blank">nbody_kernel.cu</a>")<br>
<br>involving <a href="http://bodysystemcuda.cu/" target="_blank">bodysystemcuda.cu</a> (bodysystemcuda.cpp declares ... <a href="http://bodysystemcuda.cu/" target="_blank">bodysystemcuda.cu</a> defines) one of the very files which contain the unresolved functions (allocateNBodyArrays and friends).</div>
<br>I then ask the question:<br><br>Can anyone point me on a path which would help me figure out what (global project settings) in dcmtk could be causing these kinds of changes in my unrelated nbody project?<br><br>Which I then end up answering my own question:<br>
<br>I removed (i.e. the force to use earlier version):<br><br><br># check required version of CMake<br>CMAKE_MINIMUM_REQUIRED(VERSION 2.0)<br>#IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)<br># SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of CMake when this project was released." FORCE)<br>
#ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6)<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">
<br><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div><br></div></div></div></blockquote></div>
<div><br>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.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div><br></div></div></div></blockquote>
</div></div></blockquote><div><br>Yes and I quickly learned not to touch them. I got burned.<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div><br></div></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>
<br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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)<br>
<br></blockquote></div><div><div><br>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.<br>
<br></div></div></div></blockquote><div><br>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.<br>
<br></div></div></blockquote></div><div><br>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).<br>
</div></div></blockquote><div><br>but if they would make a NVIDIASDK.cmake or CMakeLists.txt file in a known location that would not change it might not be so bad. One could only hope. Registry Key use sadens me. The very concept (the registry) is an attack on my sensibilities. I must now cleanse my thoughts with a couple of pages of Linux kernel code and thoughts of apple pie :-)<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><br><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>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):<br><br>find_package(<package> PATHS paths... NO_DEFAULT_PATH)<br>
<br></div></div></blockquote></div><div><br>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.<br>
<br></div></div></blockquote><div><br>Yes I tend to run into this kind of thing. Usually with the desire to keep my build system checkout and compile with little to no deps on host system. When I feel the need to start moving things around into my build tree is when I find out how brittle the software is.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>From FindCuda (with cmake now in my build tree so I can patch it):<br>
<br> # Search in the CUDA_BIN_PATH first.<br> find_path(CUDA_TOOLKIT_ROOT_DIR<br> NAMES nvcc nvcc.exe<br> PATHS ENV CUDA_BIN_PATH<br> DOC "Toolkit location."<br>
NO_DEFAULT_PATH<br> )<br> # Now search default paths<br> find_path(CUDA_TOOLKIT_ROOT_DIR<br> NAMES nvcc nvcc.exe<br> PATHS /usr/local/bin<br> /usr/local/cuda/bin<br> DOC "Toolkit location."<br>
)<br><br></div></div></blockquote></div><div><br>I think the reason that the find_path(CUDA_TOOLKIT_ROOT_DIR doesn't
work with the paths supplied by find_package is that your paths don't
include the bin directory, and thus misses the executable. I'll have
to look into that more, but for now you should just specify the
locations with CUDA_TOOLKIT_ROOT_DIR (as per the documentation in
FindCUDA.cmake).<br>
<br></div></div></blockquote><div><br>I gave this a try:<br><br># set( CUDA_TOOLKIT_ROOT_DIR ${CUDA_TOOLKIT_DIR} CACHE STRING "" FORCE )<br># set( CUDA_SDK_ROOT_DIR ${NVIDIA_SDK_DIR} CACHE STRING "" FORCE )<br>
<br> find_package( cuda PATHS ${CUDA_TOOLKIT_DIR} ${NVIDIA_SDK_DIR} <br> C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/CUDA_Toolkit_2.2/bin<br> C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/NVIDIA_GPU_Computing_SDK_2.2/bin<br>
NO_DEFAULT_PATH)<br><br>and it did not work. I can get it to work by commenting out the set's above.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>
<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div>Following the advice from <a href="http://www.cmake.org/cmake/help/cmake-2-8-docs.html" target="_blank">http://www.cmake.org/cmake/help/cmake-2-8-docs.html</a>:<br>
<br>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:<br>
<br> find_package(<package> PATHS paths... NO_DEFAULT_PATH)<br> find_package(<package>)<br><br>This is urrr... umm... hokey (calling multiple times). And I cannot seem to get it to work.<br></div></div></blockquote>
</div><div><br>I use this construct, because CMake will favor default paths before supplied paths, and I want to make sure that the stuff in my path is found first.<br> <br></div></div></blockquote><div><br>This is an general internal CMake construct which is not FindCUDA specific yes/no?<br>
<br> <br></div></div>-- <br>Brian J. Davis<br><br>