Skip to content

Draft: [WIP] New package realm, legion update, gasnet update - #1231

Closed
rbberger wants to merge 20 commits into
spack:developfrom
rbberger:new-package/realm
Closed

Draft: [WIP] New package realm, legion update, gasnet update#1231
rbberger wants to merge 20 commits into
spack:developfrom
rbberger:new-package/realm

Conversation

@rbberger

Copy link
Copy Markdown
Member

Realm is being split into its own repository. This starts the process of upgrading the Spack packages to reflect this new reality. This is still WIP.

@github-actions github-actions Bot added new-package Additions of new packages to the Spack ecosystem new-version Modifications to packages' `depends_on()` directives dependencies Modifications with a `depends_on()` directive resources update-package Modifications to packages in the repository conflicts Modifications with a `conflicts()` directive new-variant Modifications to packages' `variant()` directives labels Aug 28, 2025
@rbberger rbberger changed the title Draft: [WIP] New package/realm Draft: [WIP] New package realm, legion update Aug 28, 2025
@github-actions github-actions Bot removed the resources label Sep 2, 2025
@rbberger rbberger changed the title Draft: [WIP] New package realm, legion update Draft: [WIP] New package realm, legion update, gasnet update Sep 2, 2025
@rbberger

rbberger commented Sep 2, 2025

Copy link
Copy Markdown
Member Author

@PHHargrove @bonachea FYI, given the changes in Legion/Realm and how they will move forward in building, I have to push forward with these GASNet package changes to support work at LANL. I'm currently using this branch for testing, but I'm planning to move the GASNet part into its own PR. I'm explicitly doing things against the wishes/recommendations of what is documented in the comments of that Spack package and tried to update the language accordingly. I'm happy to discuss these changes here or in another forum. @elliottslaughter FYI

@rbberger
rbberger force-pushed the new-package/realm branch 2 times, most recently from 61632cb to cbacfc2 Compare September 2, 2025 23:17

homepage = "https://legion.stanford.edu/"
git = "https://github.com/StanfordLegion/legion.git"
git = "https://gitlab.com/StanfordLegion/legion.git"

@rbberger rbberger Sep 2, 2025

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self, this might have to be changed back to github. This is for testing only @elliottslaughter

@elliottslaughter

Copy link
Copy Markdown
Contributor

Let me know when you want a review on this.

@rbberger
rbberger force-pushed the new-package/realm branch 2 times, most recently from 56dff06 to 074073c Compare September 6, 2025 02:59
@github-actions github-actions Bot removed the conflicts Modifications with a `conflicts()` directive label Sep 6, 2025
@rbberger
rbberger force-pushed the new-package/realm branch 8 times, most recently from b748259 to 38ac2be Compare September 9, 2025 07:14
@mpokorny

mpokorny commented Nov 6, 2025

Copy link
Copy Markdown
Contributor

@rbberger is this something I could try out for Legion/Realm + Kokkos? I'm sort of in a jam, as my application needs to use a post 25.09 version of Legion for some new commits, and the current Spack package for Legion doesn't work correctly with +kokkos for 25.09 or later. I was able to get a successful build after modifying the current Spack package and some CMakeLists.txt files, but I'd rather try this out if it's usable in a testing situation. Note that I do not need gasnet for the tests I want to run in the near term.

@rbberger

rbberger commented Nov 6, 2025

Copy link
Copy Markdown
Member Author

@mpokorny yes, this is my most current workable state.

@mpokorny

mpokorny commented Nov 7, 2025

Copy link
Copy Markdown
Contributor

I've found one small problem, which can be solved with a patch file for, and a patch to, the realm package. The problem is a malformed string() command in CMakeLists.txt, and it exists in 25.6.1-rc.4 but not main. What's the preferred way for me to provide the needed fixes (single line addition to package.py, and one new, single-line patch file)?

@mpokorny

mpokorny commented Nov 7, 2025

Copy link
Copy Markdown
Contributor

Another issue: max_dims variant value is not being propagated from legion to realm.

@rbberger

rbberger commented Nov 7, 2025

Copy link
Copy Markdown
Member Author

@mpokorny I would wait for the actual release and not try to patch rc versions. I'll remove them prior to merge. Thanks for pointing out the missing dim propagation.

@mpokorny

Copy link
Copy Markdown
Contributor

Also, the sysomp variant isn't being propagated from legion to realm.

@rbberger

Copy link
Copy Markdown
Member Author

@mpokorny fyi, we noticed we can't build Realm with Clang as CUDA compiler due to missing fatbin compilation. So CUDA compiler has to remain nvcc, even if Kokkos was configured with Clang.

@rbberger rbberger mentioned this pull request Jan 5, 2026
@mpokorny

mpokorny commented Jan 9, 2026

Copy link
Copy Markdown
Contributor

I've run into some issues here

os.environ["KOKKOS_CXX_COMPILER"] = self["kokkos"].kokkos_cxx
with a cpu only build. There's a crash when accessing the kokkos_cxx property.
Upon inspection of the Spack packages and cmake files for Kokkos and Legion, I'm pretty certain that Legion (or Realm) doesn't use or need the value of the environment variable that is set here for any version of Kokkos >= 3.2 (or so). Given that Realm now (or soon) will require Kokkos >= 4, it should be safe to remove this line, at least conditionally. I removed it unconditionally in the cpu-only build, with no ill effect (although I still need to do more verification).

@rbberger

rbberger commented Jan 9, 2026

Copy link
Copy Markdown
Member Author

@mpokorny sry, should have told you that for the Realm changes in StanfordLegion/realm#385 I'm only using #2941 (note, no real GASNET support except external)

@rbberger

rbberger commented Jan 9, 2026

Copy link
Copy Markdown
Member Author

Given that Realm now (or soon) will require Kokkos >= 4, it should be safe to remove this line, at least conditionally

Yes, since Legion doesn't have any explicit Kokkos code paths, we don't have any direct dependency to Kokkos anymore except through Realm. So that should go away.

@mpokorny

mpokorny commented Jan 9, 2026

Copy link
Copy Markdown
Contributor

I did notice that, but since the issue I mentioned is in the Legion package, I figured that I ought to mention it. (I still have to use the Legion package here in order to build a recent Legion, modified by some of my own patches.)

@mpokorny

mpokorny commented Jan 9, 2026

Copy link
Copy Markdown
Contributor

Almost...you're forgetting about the examples, which do have Kokkos code.

@rbberger

Copy link
Copy Markdown
Member Author

Closing this one in favor of #1409 and #2997

@rbberger rbberger closed this Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Modifications with a `depends_on()` directive new-package Additions of new packages to the Spack ecosystem new-variant Modifications to packages' `variant()` directives new-version Modifications to packages' `depends_on()` directives update-package Modifications to packages in the repository

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants