[CMake] Support for Custom LANG in CMAKE (CUDA and general case)

James Bigler jamesbigler at gmail.com
Fri Jun 17 17:53:54 EDT 2011


On Fri, Jun 17, 2011 at 11:12 AM, t m <cmake at majchrowski.co.uk> wrote:

> > As far as I correctly understood patch from Peter, implementation for
> > makefile dependency is on place.
> > For me makefile dependency is fine, since I'm using only makefiles.
> >
> > I just tried to understand idea of LANGUAGE inside cmake. I think that
> > in this particular case having new language on place is really good
> > idea. This is what for language was.
>
> I will also vote for this solution. Since there is no difference in
> the workflow why to use separate macros and separate implementation.
> Why to not simply reuse LANG interface and C/CPP dependency scanner.
> The same analogy is in case of C and CXX - there is no
> distinguish like: c_add_executable and cxx_add_executable.
>
> regards, Tomasz Majchrowski.
> _______________________________________________
> 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
>

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.

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.

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.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110617/baece9a3/attachment-0001.htm>


More information about the CMake mailing list