On Thu, Jan 7, 2010 at 5:08 PM, Brian Davis <bitmi...@gmail.com> wrote:
>
>
>
>
>> 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."
>>> )
>>>
>>>
>> 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).
>>
>>
> I gave this a try:
>
> # 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/bin
>
> C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/NVIDIA_GPU_Computing_SDK_2.2/bin
> NO_DEFAULT_PATH)
>
> and it did not work. I can get it to work by commenting out the set's
> above.
>
>
Sure that didn't work, because the find_path command was looking for nvcc in
${CUDA_TOOLKIT_DIR} instead of looking for bin/nvcc in ${CUDA_TOOLKIT_DIR}.
I suspect if you changed find_package to use ${CUDA_TOOLKIT_DIR/bin it might
work, though for 64 bit builds it would have to be
${CUDA_TOOLKIT_DIR}/bin64. I'll see if I can experiment with this a bit
more and figure out what is the right solution to make both of these
scenarios work.
>
>
>>
>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>
> This is an general internal CMake construct which is not FindCUDA specific
> yes/no?
>
Yes, this is how CMake works. The documentation for the find_XYZ functions
explains the search order, and subsequent emails to mailing list helped me
settle determine that this construct is the only way to obtain the needed
functionality. Perhaps CMake could be augmented with a
"USE_SUPPLIED_PATHS_FIRST" argument to change the search ordering to help
avoid having to run the command twice.
James
_______________________________________________
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
