Provide proper CMake module support
harrism opened this issue · comments
Prompted by discussion in rapidsai/rmm: rapidsai/rmm#883 (review)
Projects that use RMM along with other libraries that depend on libcudacxx can end up with multiple installs of libcudacxx. Proper cmake module support can avoid this problem and make the library easier to depend on for CMake projects.
I'm not an expert on CMake module support, so I'm not exactly sure what work this entails. CC @robertmaynard
It's going to be tricky to figure out how libcudacxx will fit in with CMake's FindCUDAToolkit:
For instance, what namespace should libcu++'s exported targets live in? Should they be CUDA::libcudacxx, like the FindCUDAToolkit targets? Or libcudacxx::libcudacxx like a standalone project?
There are also many issues with being both standalone and a CTK project, mainly due to the implicit inclusion of ${CTK_PREFIX}/include. By default, the include directories of IMPORTED CMake targets are added with -isystem, which is checked after the implicit CTK include path during lookup.
It's possible to work around this. Thrust/CUB do some nasty hacks, and CMake is adding a property to allow IMPORTED targets to use -I in the next version. There are also more subtle issues that can make life difficult for users caused by this include.
We may want to consider moving CCCL headers from ${CTK_PREFIX}/include to ${CTK_PREFIX}/include/${project}. It would make life much easier for standalone users. CTK users would have to add an extra include dir, and maybe we could ask for an -ictk option (e.g. nvcc -ictk=libcudacxx == nvcc -isystem=${CTK_PREFIX}/include/libcudacxx) to simplify things for users.