cmake: move kokkos files into subdirectory - #385
Merged
elliottslaughter merged 1 commit intoJan 9, 2026
Conversation
rbberger
force-pushed
the
kokkos_cmake_refactor
branch
4 times, most recently
from
January 9, 2026 01:48
f415ede to
acf34da
Compare
Contributor
Author
|
@elliottslaughter @muraj This is ready for review and testing on your end. Together with the Spack package change, this should significantly improve the situation. |
muraj
approved these changes
Jan 9, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #385 +/- ##
=======================================
Coverage 27.74% 27.74%
=======================================
Files 192 192
Lines 39502 39502
Branches 14382 14382
=======================================
Hits 10959 10959
Misses 28151 28151
Partials 392 392 ☔ View full report in Codecov by Sentry. |
Contributor
|
@rbberger Do you mind signing the commits? |
We end up with two cases: A. Shared build realm_kokkos is a shared library and self-contained. Linking to it doesn't propagate link options. B. Static build realm_kokkos is a static library and inherits the Kokkos INTERFACE link options. This forces us to use the same linker/wrapper as Kokkos in this case. Signed-off-by: Richard Berger <rberger@lanl.gov>
rbberger
force-pushed
the
kokkos_cmake_refactor
branch
from
January 9, 2026 19:15
acf34da to
1510369
Compare
Contributor
Author
|
@elliottslaughter done |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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)