-
Notifications
You must be signed in to change notification settings - Fork 9
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
Spack CPU build exago~mpi
#47
base: develop
Are you sure you want to change the base?
Changes from all commits
08a713f
a014957
aec2713
64c9d64
51d6802
6dcc180
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,17 +14,14 @@ jobs: | |
# Minimal Build(s) | ||
# Need S3 mirror to have these builds speedup | ||
spack_spec: | ||
# See #39 - ~python~mpi causes issues | ||
# - exago@develop~mpi~ipopt~hiop~python~raja | ||
# See #44 - +mpi~python should fail if no python in system, | ||
# but the runner happens to have one... | ||
- exago@develop+mpi~ipopt+hiop~python~raja ^openmpi | ||
# See #39 - minimal build useful for sanity | ||
- exago@develop~mpi~ipopt~hiop~python~raja | ||
# See #16 / #44 - +python~mpi catches mpi4py / python config | ||
- exago@develop~mpi~ipopt~hiop+python~raja | ||
# See #18 - +hiop~mpi causes issues | ||
# - exago@develop~mpi~ipopt+hiop~python+raja | ||
# See #16 - +python~mpi causes issues | ||
# - exago@develop~mpi~ipopt+hiop+python~raja | ||
- exago@develop+mpi~ipopt+hiop+python~raja ^openmpi | ||
# See #40 - +hiop+raja~ipopt ^hiop~sparse is useful for edge cases | ||
# See #40 - +hiop+raja~ipopt ^hiop~sparse is useful for edge cases in xSDK | ||
- exago@develop+mpi~ipopt+hiop~python+raja ^openmpi ^hiop+raja~sparse | ||
|
||
name: Build ExaGO with Spack | ||
|
@@ -41,8 +38,10 @@ jobs: | |
SPACK_SPEC: ${{ matrix.spack_spec }} | ||
run: | | ||
ls && pwd | ||
. ./tpl/spack/share/spack/setup-env.sh | ||
. /opt/spack/share/spack/setup-env.sh | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is more sustainable, and can be swapped out when we want to use ExaGO's spack. It might just make more sense to have a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The spack repo is is incredibly active, I would be hesitant to pin a version of spack because that's just another package we would could get hung up on a "blessed" version or forget to upgrade that one clone... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To clarify, for 100% reproducible spack builds we need to pin the version in certain situations (such as profiling runs, or key performance runs). For CI and automated builds, I do think that just using spack's develop like we do with this base image is the best way to go. Is that in line with what you were thinking? |
||
spack debug report | ||
spack mirror add spack_public_mirror https://binaries.spack.io/develop | ||
spack buildcache keys --install --trust | ||
spack env create -d ./spack-env | ||
spack env activate ./spack-env | ||
spack add $SPACK_SPEC target=x86_64 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue in
+mpi~python
should be equivalent to a build with~mpi~python
as far as I can tell. Either way I think this is sufficient and we need to ensure these builds pass in future.