cmake: move kokkos files into subdirectory #385
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This refactor moves the kokkos interop code into its own subdirectory. This allows us to isolate, for the most part, the Kokkos compilation from the rest of the Realm build. This removes the client restriction to use Kokkos with
-DKokkos_ENABLE_COMPILE_AS_CMAKE_LANGUAGE=ON.We end up with two cases:
Shared build
realm_kokkosis a shared library and self-contained. Linking to it doesn't propagate link options.Static build
realm_kokkosis a static library and inherits the KokkosINTERFACElink options. This forces us (and our clients) to use the same linker/wrapper as Kokkos.Spack package changes
The new Realm spack package enforces these two cases and acts accordingly. The most isolated build is the shared library. For the static build we must use the same compiler/wrapper as Kokkos. In addition, we must ensure that Realm uses the same GCC and Clang as Kokkos.
spack/spack-packages#2941
Below is a Spack environment used for verifying the builds in various combinations:
Note
Not all combinations in the Spack test environment pass due to Kokkos and CMake issues in certain combinations, but this change significantly increases the functional combinations. (40/44)
Known Issues:
kokkos+shared+cuda+cmake_lang %cxx=clangkokkos~shared+cuda_cmake_lang %cxx=clangThe problem here is that Kokkos uses
clang++asCMAKE_CUDA_COMPILER, however, there is no good way of changing that compiler in a subdirectory. MixingCMAKE_CUDA_COMPILER=nvccandCMAKE_CUDA_COMPILER=clang++in a single CMake build seems to cause issues. So the better solution will be to useclangall the way in that case. However, as we've seen, this requires: #368Spack Test Environment for testing combinations (on Ubuntu 24.04 with CUDA 12.8 and ROCm 6.4.3 installed)