On Tue, Jun 14, 2011 at 5:18 AM, Łukasz Tasz <span dir="ltr"><<a href="mailto:lukasz@tasz.eu">lukasz@tasz.eu</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;">
Hi all,<br>
<div class="im"><br>
><br>
> Other than the 'more elegant' prospect of being able to just put .cu files<br>
> into a target, is there anything else deficient about the current FindCUDA<br>
> macros? All you have to do really is to use cuda_add_executable instead of<br>
> add_executable.<br>
><br>
<br>
</div><div class="im">As far as I understood the topic aim is to provide object compiled<br>
with different language - in this case with CUDA.<br>
But respecting dependencies that are visible on all platform. Since<br>
*.cu files are like C++ syntax, same dependency generator from cmake<br>
can be used.<br>
<br>
The aim is to provide add_executable(demo main.cxx <a href="http://demo1.cu" target="_blank">demo1.cu</a> <a href="http://demo2.cu" target="_blank">demo2.cu</a>)<br>
or add_executable(demo <a href="http://main.cu" target="_blank">main.cu</a> <a href="http://demo1.cu" target="_blank">demo1.cu</a> <a href="http://demo2.cu" target="_blank">demo2.cu</a>),<br>
The first example will be only partialy compiled by CUDA.<br>
<br></div></blockquote><div><br>I don't understand what you mean by partially. If you had cuda_add_executable(demo main.cxx <a href="http://demo1.cu">demo1.cu</a> <a href="http://demo2.cu">demo2.cu</a>), then main.cxx will be compiled by the host compiler, <a href="http://demo1.cu">demo1.cu</a> and <a href="http://demo2.cu">demo2.cu</a> will be compiled by nvcc (CUDA + host compiler), and then all will be linked by the host linker.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
</div><div class="im">> I've iterated with Peter many times about his proposed changes, and one of<br>
> the issues we were hoping to solve is the ability to target different output<br>
> formats. CUDA supports generation of not only object files, but PTX and<br>
> CUBIN files which need to not be treated as an object file. In addition, it<br>
> wasn't clear how this adaptation would behave along side the existing<br>
> FindCUDA behavior for which we have to be backward compatible with.<br>
<br>
</div><div class="im">In this case cmake gives very flexible way of introducing new<br>
language, just correctly initialise all *<LANG>* variables,<br>
But one very important thing is gone, dependencies. There is no<br>
interface how to provide dependencies / generate dependencies for<br>
cmake. (at least I don't know - making macro that will ccan the files<br>
for #includes and calling add_dependencies is not a solution)<br>
<br>
It would be really nice to have this language included, or even more<br>
flexible solution is also welcome, to get intercafe to impement own<br>
dependency scaner or inherit current one (C/CXX)<br>
<br>
<br>
regards<br>
Lukasz Tasz<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
<br></div></div></blockquote><div><br>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?<br>
<br>James <br></div></div><br>