GitLab

Currently, CUDA as a language is missing architecture specifications. This should be added to allow users to migrate from FindCUDA. The first implementation, !1975 (closed), simply adapted the old function to make it a usable module for the CUDA language.

Injecting --generate-code= flags like this assumes that NVCC is the compiler. Other compilers may use other flags (e.g. Clang's --cuda-gpu-arch=). COMPILE_OPTIONS is typically meant for project code to set to add flags for which CMake offers no other abstraction. Low-level things like CUDA architecture selection should have first-class abstractions in CMake.

For example, we could have a CUDA_ARCHS target property and INTERFACE_CUDA_ARCHS equivalent for propagating usage requirements. The generators would transform this into the proper flags for the current compiler. VS generators could generate the proper .vcxproj file content without having to map flags.

Here's my summary of the proposed design:

• Add two new properties, CUDA_ARCHS and INTERFACE_CUDA_ARCHS, that start empty and accept a list of numerical values.
• Add a CMAKE_CUDA_ARCHS variable to initialize
• Use a modified version of cmake_cuda_arch_select in !1975 (closed); it should only give a list of numerical arches as a result that could be used to set the CUDA_ARCHS. This would be the only part that needs to know about actual CUDA versions and allowed arch values.
• The old version of the function could convert arch values into flags
• NVCC generator would convert to flags as needed. Other generators, like clang, would be able to translate the numerical list into their correct flags (see #16586 (closed))

Thoughts:

• Think about arch vs. code flags. Could virtual/code architecture be abstracted away, or are two variables needed, CUDA_ARCHS and CUDA_CODES?