Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add specs for conduit tests #10

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

add specs for conduit tests #10

wants to merge 3 commits into from

Conversation

cyrush
Copy link
Member

@cyrush cyrush commented Sep 9, 2021

No description provided.

@adrienbernede
Copy link
Member

@cyrush For the duration of your PR, you should change ENV_NAME to be conduit in .gitlab-ci.yml.
I am actively trying to find a better way.

@adrienbernede
Copy link
Member

Right now, it triggered a pipeline for the radiuss environment, because that’s the default.

@cyrush
Copy link
Member Author

cyrush commented Sep 9, 2021

A few notes:

The system configs (packages.yaml) are based off of @davidbeckingsale's - however they are not exactly the same b/c:

I need to test building conduit's python support -- and since it extends python, spack has to build python as part of the process.

@adrienbernede
Copy link
Member

One way we could "uniformize" this would be to agree on a limit for things to share, and things that should be in the project spack.yaml:

  • We share CMake -> packages.yaml (shared)

  • We share compilers -> compilers.yaml (shared)

  • We share Cuda -> packages.yaml (shared)

  • We share MPI -> packags.yaml (shared)

  • We don’t share python -> spack.yaml (project specific)

Then the questions is: what about small utilities (m4, pkg-config, and such)?

@adrienbernede
Copy link
Member

That’s because we can have two source for the packages: section.

@adrienbernede
Copy link
Member

Note: clingo compiler takes ages, that’s what we are looking for at the moment.

@cyrush
Copy link
Member Author

cyrush commented Sep 9, 2021

this is where my head starts to spin - I feel like we get into a scenario where we need scripts to combine (override, union) shared packages. Solving this in a nice way would make sharing all of these things much much easier.

@adrienbernede
Copy link
Member

If only we knew the nice way :)
The only way I see is to define rules. But maybe I just have blinders!

@davidbeckingsale
Copy link
Member

Does spack configs allow this kind of "overriding" with multiple environments? A bit like how you can have repos that override packages...

@adrienbernede
Copy link
Member

@davidbeckingsale my impression is that we can override part of the configs directly in the spack.yaml:

  • We include the shared config as a starting point.
  • We define locally to the spack.yaml what we want that is specific.

I don't know if there is such a thing as stackable environments. All I know is that environment modularity is currently being revisited by @becker33

@adrienbernede
Copy link
Member

@cyrush I hope the lassen jobs are producing useful input (there was a failure of one conduit spec).

In the meantime, I am trying to decrypt the "KeyError" on quartz.

@adrienbernede
Copy link
Member

Believe it on not but it looks like just today there were 2 changes in spack@develop that "alter" things in our pipelines.
It is creating a combo error that is tough to debug, but I was in touch with @scottwittenburg and we identified a path forward to find where the issue comes from exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants