On Tue, Jun 14, 2011 at 5:18 AM, Łukasz Tasz <[email protected]> wrote:
> Hi all, > > > > > Other than the 'more elegant' prospect of being able to just put .cu > files > > into a target, is there anything else deficient about the current > FindCUDA > > macros? All you have to do really is to use cuda_add_executable instead > of > > add_executable. > > > > As far as I understood the topic aim is to provide object compiled > with different language - in this case with CUDA. > But respecting dependencies that are visible on all platform. Since > *.cu files are like C++ syntax, same dependency generator from cmake > can be used. > > The aim is to provide add_executable(demo main.cxx demo1.cu demo2.cu) > or add_executable(demo main.cu demo1.cu demo2.cu), > The first example will be only partialy compiled by CUDA. > > I don't understand what you mean by partially. If you had cuda_add_executable(demo main.cxx demo1.cu demo2.cu), then main.cxx will be compiled by the host compiler, demo1.cu and demo2.cu will be compiled by nvcc (CUDA + host compiler), and then all will be linked by the host linker. > > > I've iterated with Peter many times about his proposed changes, and one > of > > the issues we were hoping to solve is the ability to target different > output > > formats. CUDA supports generation of not only object files, but PTX and > > CUBIN files which need to not be treated as an object file. In addition, > it > > wasn't clear how this adaptation would behave along side the existing > > FindCUDA behavior for which we have to be backward compatible with. > > In this case cmake gives very flexible way of introducing new > language, just correctly initialise all *<LANG>* variables, > But one very important thing is gone, dependencies. There is no > interface how to provide dependencies / generate dependencies for > cmake. (at least I don't know - making macro that will ccan the files > for #includes and calling add_dependencies is not a solution) > > It would be really nice to have this language included, or even more > flexible solution is also welcome, to get intercafe to impement own > dependency scaner or inherit current one (C/CXX) > > > regards > Lukasz Tasz > _______________________________________________ > > The problem with dependencies I think relates to how the build system represents them. In makefiles the dependencies are explicitly defined, while in Visual Studio the dependencies for C code is handled by the IDE and other files are explicit. It seems like a lot of effort to extend CMake dependency scanning capabilities when this functionality can only be extended to makefiles. Is this what you are desiring? 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
