# Detecting if a target has CUDA sources with separable compilation

**URL:** <https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767>\
**Category:** Code\
**Created:** [March 17, 2025, 8:09pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767 "2025-03-17T20:09:40Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![pcanal](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pcanal/32/5413_2.png) [@pcanal](https://discourse.cmake.org/u/pcanal)\
**Post date:** [March 17, 2025, 8:09pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/1 "2025-03-17T20:09:40Z")

</div>

In the context of this project: [GitHub - celeritas-project/CudaRdcUtils: CMake utility functions for building and linking libraries containing CUDA relocatable device code](https://github.com/celeritas-project/CudaRdcUtils)  
that help solve the NVidia Relocatable Device Code conundrum.

We need to loop over the sources of a library (to see if any are CUDA sources). We acquire the sources via:

```auto
get_target_property(_target_sources library_name SOURCES )

```

and then loop through them via:

```auto
  foreach(_source "${${ARGN}}")
    get_source_file_property(_iscudafile "${_source}" LANGUAGE)
    ...
  endforeach()

```

and this work nicely in almost of cases.

However some users decided to use this ‘legal’ looking pattern:

```auto
add_library(library_name somefile.cxx $<$<BOOL:${_USERPROJECT_ENABLE_CUDA}>:SomeCudaFile.cu;AnotherCudaFile.cu> otherfile.cxx)

```

And this gets screwed up because the successive values of `_source` are (one by line):

```auto
somefile.cxx
$<$<BOOL:ON
SomeCudaFile.cu
AnotherCudaFile.cu
otherfile.cxx

```

Instead of having the `$<$<BOOL:ON>:SomeCudaFile.cu;AnotherCudaFile.cu>` as a second line (out of 3). There is also no way to reconstruct it as the end is not marked as anyway.

Short of demanding the user to change their code, what are the option to handle this situations?  
(this is related to CMake challenges with nested list).

---

<div class="post-metadata">

**Author:** ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)\
**Post date:** [March 17, 2025, 8:18pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/2 "2025-03-17T20:18:08Z")

</div>

Cc: @robert.maynard

> [@pcanal](#):
>
> We need to loop over the sources of a library (to see if any are CUDA sources).

Since the list of sources can depend on generator expressions, even CMake itself doesn’t know the answer to that question until generate time. It is not possible to know this information at configure time in general. What do you want to do in response to it?

---

<div class="post-metadata">

**Author:** ![pcanal](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pcanal/32/5413_2.png) [@pcanal](https://discourse.cmake.org/u/pcanal)\
**Post date:** [March 17, 2025, 8:29pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/3 "2025-03-17T20:29:00Z")

</div>

If the whole generator expression was passed as a single item (instead of N items), at the very least we could ‘skip’ it or probably better I could detect that it is a generator expression and either

- tell the user that generator expression are not support
- or even look at its components

Stepping back, is there a better way to answer the question:

- Is there any CUDA source file in this library
- and is cuda separatable compilation enabled for the library

Context:  
if the condition above are true (and this library needs to be used by any other library), the only solution (that we know of) to properly handle nvcc and nvlink quirks is to replace that single library by 3 libraries files (an object library, a static library and a ‘final’ library). This is because an executable can (in practice due to the nvlink implementation) load one and only one result of nvlink (which was invoked passing the .o (eg. final static libraries) for all the Relocatable Device Code libraries involved in that executable).

---

<div class="post-metadata">

**Author:** ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)\
**Post date:** [March 17, 2025, 8:38pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/4 "2025-03-17T20:38:24Z")

</div>

> [@pcanal](#):
>
> at the very least we could ‘skip’ it

You can use [`string(GENEX_STRIP)`](https://cmake.org/cmake/help/v4.0/command/string.html#genex-strip) to filter out generator expressions before iterating.

> [@pcanal](#):
>
> - Is there any CUDA source file in this library
> - and is cuda separatable compilation enabled for the library

In general these questions cannot be answered at configure time unless you ask the project to tell you explicitly through some other method.

---

<div class="post-metadata">

**Author:** ![pcanal](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pcanal/32/5413_2.png) [@pcanal](https://discourse.cmake.org/u/pcanal)\
**Post date:** [March 17, 2025, 8:41pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/5 "2025-03-17T20:41:36Z")

</div>

> You can use [`string(GENEX_STRIP)`](https://cmake.org/cmake/help/v4.0/command/string.html#genex-strip) to filter out generator expressions before iterating.

Thanks.

> In general these questions cannot be answered at configure time unless you ask the project to tell you explicitly through some other method.

This sounds like the conclusion would be that the concept prototyped in [GitHub - celeritas-project/CudaRdcUtils: CMake utility functions for building and linking libraries containing CUDA relocatable device code](https://github.com/celeritas-project/CudaRdcUtils) can then only be implemented by CMake proper (i.e. at generation time), isn’t it?

---

<div class="post-metadata">

**Author:** ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)\
**Post date:** [March 17, 2025, 8:48pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/6 "2025-03-17T20:48:34Z")

</div>

> [@pcanal](#):
>
> can then only be implemented by CMake proper (i.e. at generation time)

Likely yes.

---

<div class="post-metadata">

**Author:** ![pcanal](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pcanal/32/5413_2.png) [@pcanal](https://discourse.cmake.org/u/pcanal)\
**Post date:** [March 17, 2025, 8:55pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/7 "2025-03-17T20:55:43Z")

</div>

Is anyone that works in the innards of CMake interest in incorporating the concept and thus add ‘proper’ support nvcc’s relocatable device code? The above mentioned script is used by a couple of projects and is decent starting point.

---

<div class="post-metadata">

**Author:** ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)\
**Post date:** [March 17, 2025, 8:59pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/8 "2025-03-17T20:59:42Z")

</div>

No one is currently working on CMake support for CUDA relocatable device code AFAIK. Please open an issue to propose it, at least to have a common tracking point.

---

<div class="post-metadata">

**Author:** ![pcanal](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pcanal/32/5413_2.png) [@pcanal](https://discourse.cmake.org/u/pcanal)\
**Post date:** [March 18, 2025, 4:01pm UTC](https://discourse.cmake.org/t/detecting-if-a-target-has-cuda-sources-with-separable-compilation/13767/9 "2025-03-18T16:01:43Z")

</div>

The issue was opened at [https://gitlab.kitware.com/cmake/cmake/-/issues/26780](https://gitlab.kitware.com/cmake/cmake/-/issues/26780)