On Fri, Jun 17, 2011 at 11:12 AM, t m <span dir="ltr"><<a href="mailto:cmake@majchrowski.co.uk">cmake@majchrowski.co.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> As far as I correctly understood patch from Peter, implementation for<br>
> makefile dependency is on place.<br>
> For me makefile dependency is fine, since I'm using only makefiles.<br>
><br>
> I just tried to understand idea of LANGUAGE inside cmake. I think that<br>
> in this particular case having new language on place is really good<br>
> idea. This is what for language was.<br>
<br>
</div>I will also vote for this solution. Since there is no difference in<br>
the workflow why to use separate macros and separate implementation.<br>
Why to not simply reuse LANG interface and C/CPP dependency scanner.<br>
The same analogy is in case of C and CXX - there is no<br>
distinguish like: c_add_executable and cxx_add_executable.<br>
<br>
regards, Tomasz Majchrowski.<br>
<div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br>I dismissed the idea of using the cmake dependency scanner, because it was a makefile only solution. I wasn't interested in maintaining multiple code paths. It's much better for testing to have it work basically the same way everywhere.<br>
<br>Oh, and treating CUDA files as C++ files is fine for some situations, but CUDA can target other types of targets (PTX and CUBIN) which are not OBJ files and shouldn't be linked in. This could probably be worked around with some source file properties, so it isn't a showstopper.<br>
<br>Also, in order to make the dependency scanning work properly the dependency scanner would have to be taught about things such as target architectures which can cause certain preprocessor flags to be defined (since these preprocessor flags can be used to change which headers get included) and it would have to be made consistent with CUDA and kept up to date. It seemed a better solution to use the built in dependency generation in nvcc.<br>
<br>James<br>