MantisBT - CMake
View Issue Details
0014559CMakeCMakepublic2013-11-11 11:072016-06-10 14:31
Derek Chow 
James Bigler 
normalminoralways
closedmoved 
WindowsWindows7/8
CMake 2.8.11 
 
0014559: 0013084 fix has no backwards compatibility
See http://public.kitware.com/Bug/view.php?id=13084 [^]

"It is possible to add a variable which will define to use old and new behavior. By default to use old behavior."

I don't mind if the default is this new behaviour but there seems to be lacking a variable or option to set for the previous behaviour so that it is possible to optionally link with cuda.lib in CUDA_ADD_LIBRARY().
No tags attached.
related to 0013084closed James Bigler FindCUDA is adding libcuda.so, but this is part of driver and not CUDA Runtime. 
Issue History
2013-11-11 11:07Derek ChowNew Issue
2013-11-12 08:53Brad KingRelationship addedrelated to 0013084
2013-11-12 08:54Brad KingAssigned To => James Bigler
2013-11-12 08:54Brad KingStatusnew => assigned
2013-11-12 12:37James BiglerNote Added: 0034437
2016-06-10 14:29Kitware RobotNote Added: 0042418
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0034437)
James Bigler   
2013-11-12 12:37   
The thing is, is that the default behavior was designed around the cuda runtime, of which cuda.lib isn't a part of. It was actually a bug to link against the driver API library to begin with. I'm not sure I want to support a buggy feature in a backward compatible way.

Note, that you can link against the driver API library easily with target_link_libraries(mytarget ${CUDA_CUDA_LIBRARY})
(0042418)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.