On Sat, Jan 17, 2015 at 8:13 AM, Adam Strzelecki <o...@java.pl> wrote:
> 1. Support for dependency scanning. If I change a header included by > file.cu I want file.cu to be recompiled. This is easy for makefiles, > hard for anything else. > > > .cu is superset of C++ so it should be pretty easy to get dependency > scanning working same as for regular .cpp/.h files using CMake facilities. > > CMake doesn't support dependency scanning for Visual Studio. > 2. In the past there have been bugs with nvcc, such as leaving a partially > written output file during generation that failed, that FindCUDA has worked > around. > > > I don't see why we should care about that? If they still exist isn't it > what NVIDIA partner bug report site is for? > > It may not be my fault, but it's my problem. If I can correct for problems and help others not have to deal with those same problems, I'm going to do that. We all have to deal with imperfect tools, and not all of us can wait for 1-2 years for bugs to be fixed. > 3. Host flags generally need to be propagated to the CUDA flags (I'll > admit that this support in FindCUDA isn't perfect). > > > You mean user-defined preprocessor definitions or compiler flags? Host > compiler flags are picked up by nvcc from host compiler itself. Aside of > that, CMake will insert -D definitions as well to any extra compiler. > > So you may only want to wrap CMAKE_CXX_FLAGS into CMAKE_CUDACXX_FLAGS > using -Xcompiler which can be tricky, but I believe we can workaround that > somehow. > > 4. How do you support other targets besides cubin (obj), such as PTX? > > > For what purpose? Debugging? > > CUDA supports two usage APIs. The runtime API that is used when you compile your code to object files, and the driver API that compiles to PTX or CUBIN and then loads that code into the driver directly. FindCUDA supports both. > 5. How would separable compilation work? Especially since you can't > easily replace the linker. > > > Correct me if I am wrong, but we will still use platform linker. > > You can't use the platform linker for separable compilation unless you also produce intermediate linkage files. In order to produce intermediate linkage files you need all the object files compiled with separable linking to be run through another tool that produces this intermedate link file that will also need to be linked into the executable module. > 6. If you support PTX, can you use the output as input for other custom > commands (I like to encode the PTX into strings compiled into C++ files > using bin2c from CUDA). > > > Again can you please elaborate more why would you like to handle PTX > yourself if CUDA does it for you, i.e.: > > nvcc -arch sm_30 -> makes .o contain native device code > nvcc -arch compute_30 -> makes .o contain ptx code compiled later by the > driver itself > > This sounds like some custom behavior. > See my comment above regarding the driver versus runtime CUDA API. Yes it is different behavior, but I was able to accommodate both compilation models with the same tool. I would love for what you propose to work for both compilation modes, so if it is possible I would like to design it in. Otherwise it can't be a complete replacement for FindCUDA. James
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers