-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Telcon: 2016 06 16
Todd Gamblin edited this page Jun 16, 2016
·
19 revisions
- Matt Belhorn (ORNL)
- Ben Boeckel (Kitware)
- Mike Collette (LLNL)
- Elizabeth Fischer (NASA)
- Robert French (ORNL)
- Jim Galarowicz (Krell)
- Todd Gamblin (LLNL)
- Patrick Gartung (Fermi)
- Kenneth Hoste (HPC U. Ghent)
- Greg Lee (LLNL)
- Matt Legendre (LLNL)
- Erik Schnetter (Perimeter)
- Peter Scheibel (LLNL)
newarch
is (finally) merged todevelop
!
-
Thanks to Mario and Greg!
-
Adds Cray support.
-
Adds module-loaded compilers.
-
Adds concepts of
platform
/os
/target
to specs- platforms can have
frontend
andbackend
operating systems- e.g.
sles11
,CNL10
,elcapitan
,yosemite
,sierra
,rhel6
,rhel7
- e.g.
- OS's can have
targets
(e.g.,x86_64
,haswell
,ivybridge
)
- platforms can have
-
compilers.yaml
no longer hierarchical; has per-compilercompiler:
entry. -
Install layout is changed
-
I expect there will be a few bugs to shake out, but they should hopefully not be major ones that require a lot of rebuilding or incompatibility between versions.
-
Things to expect:
- this update will create installations that are not compatible with older versions of Spack.
- new
compilers.yaml
- new fields in
spec.yaml
files in installation directories.
- new
- hashes of the "same" package will be different, so you'll need rebuilds.
- architecture replaced with platform/os/target, so you may need to revise packages
- tried to revise the ones in the mainline.
- New way to check for mac os x:
spec.satisfies('platform=darwin')
- install layout changed -- no more
SYS_TYPE
.- install layout now reflects the new architecture.
- this update will create installations that are not compatible with older versions of Spack.
-
Next large(ish) PR: build dependencies
-
spack find
no longer shows variants by default
- add
-v
flag to get the variants - packages like boost can make the variant view awkward
- Improved padding for packages with lots of variants.
- How to release things in a more stable way?
- Spack releases are probably too infrequent
- see post on the mailing list
- Releasing at well-defined times seems like a good idea, but a release should also imply a certain level of testing and reliability.
- need to integrate testing with the release process; currently not automated enough to do it frequently.
- Reasons:
- Getting build bot setup at LLNL has been slow -- this will help.
- Proper build tests are a must for long-term stability
- Need multi-arch, multi-compiler testing and notion of what is stable.
- platform-specific
packages.yaml
can help with this.- sensible defaults, per-platform "stable" stack at any time.
- platform-specific
- Currently we really only do unit tests via travis
- Other build tests rely on the devs and community
- Need multi-arch, multi-compiler testing and notion of what is stable.
- Plan going forward: focus on getting real build testing up and running.
-
Corporate Sponsorship
-
Flake8 hate
- need to:
- document the process for users to run
flake8
themselves
- boils down to: run
share/spack/qa/run-flake8*
- this should be made into a spack command.
- make a pass over the repo to flake8-ify things.
- Change to 100-column line limit
- document the process for users to run