You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
rapids-cmake offers rapids_cuda_init_runtime, which implicitly changes the (default) CUDA linking behavior for all subsequent targets. This implicit behavior makes it difficult for consumers to reason about the CUDA linking behavior of targets since the resulting code is order-dependent and may be overridden by settings on particular targets.
Describe the solution you'd like
We should consider implementing a new function that accepts a target and adds a linkage to the appropriate CUDA library (dynamic or static) based on a function parameter. We could implement this either via a direct target_link_libraries call under the hood, or by creating a helper target (e.g. add_library(rapids_cmake_cuda_lib...)) that encodes the linkage, similar to how we handle conda in rapids_cmake_conda_env. If we wanted to incorporate math libraries we could include those as well, but we need to ensure that those are not constrained to the same type as the CUDA runtime (since the most common long-term behavior we want to encourage is statically linking cudart but dynamically linking the math libraries). We may instead benefit more from creating a separate function to handle the math library linkage.
The text was updated successfully, but these errors were encountered:
We can't go with an API that maches rapids_cmake_conda_env style. The problem is that we need to set a property on the target which isn't possible via linking to a target.
This would cause uses_cuda to initialize the target property CUDA_RUNTIME_LIBRARY to the correct value, and also link to CUDA::cudart or CUDA::cudart_static.
Is your feature request related to a problem? Please describe.
rapids-cmake offers
rapids_cuda_init_runtime
, which implicitly changes the (default) CUDA linking behavior for all subsequent targets. This implicit behavior makes it difficult for consumers to reason about the CUDA linking behavior of targets since the resulting code is order-dependent and may be overridden by settings on particular targets.Describe the solution you'd like
We should consider implementing a new function that accepts a target and adds a linkage to the appropriate CUDA library (dynamic or static) based on a function parameter. We could implement this either via a direct
target_link_libraries
call under the hood, or by creating a helper target (e.g.add_library(rapids_cmake_cuda_lib...)
) that encodes the linkage, similar to how we handle conda inrapids_cmake_conda_env
. If we wanted to incorporate math libraries we could include those as well, but we need to ensure that those are not constrained to the same type as the CUDA runtime (since the most common long-term behavior we want to encourage is statically linking cudart but dynamically linking the math libraries). We may instead benefit more from creating a separate function to handle the math library linkage.The text was updated successfully, but these errors were encountered: