Open bernhardmgruber opened 3 weeks ago
OK, so this requires some restructuring:
The C2H static libraries (helper and Catch2 main libraries) depend on CCCL and thus on CUB and Thrust. Since the implementation of C2H makes use of CUB in several places and has CUDA specific workarounds (e.g. checked allocator for c2h::device_vector
) and features (cuBLAS), we need a CUDA compiler to compile C2H. Also, since no Thrust backend is specified in CMake, it uses the CUDA backend.
The Thrust unit tests are generated and compiled for each Thrust backend. Any non-CUDA Thrust unit test linking against C2H now fails to configure in CMake, because the Thrust backend CMake property is different. It would also fail later if we could work around this, since we would want C2H use the Thrust backend that is also configured for the unit test.
Using C2H for Thrust unit tests configured for the CUDA backend works with little effort: the CMake integration is not that complex. However, for the general solution we would need C2H, or a useful part of it, to compile without CUDA so it can be used by Thrust. The CUDA part of C2H would then only be used by CUB, or any future CUDA project we want to test. I will have a look on how complex such a split would be.
I think I got most of C2h working with Thrust's generic interface. The big blocker is now that we compile one C2H target linking against Thrust. However, later when compiling Thrust unit tests we want to link against C2H with different systems active. This would now require us to replicate the multisystem Thrust config to C2H, which looks painful.
Since Catch2 and the corresponding helpers (c2h) have been moved out of CUB into a separate library in #2615, the way has been paved to allow Catch2 tests in Thrust. This will require some CMake modifications to Thrust. For the short and medium term, we will have to support a mix of Catch2 and non-Catch2 (legacy) tests in Thrust. This should be handled the same way as in CUB.