Telcon: 2017 02 23

Participants

On the call

1. Todd Gamblin (LLNL)
2. Greg Becker (LLNL)
3. Greg Lee (LLNL)
4. Kiel Friedt (LLNL)
5. Matt Legendre (LLNL)
6. Mario Melara (NERSC)
7. Paul Hopkins (Cardiff, LIGO collab.)
8. Peter Scheibel (LLNL)
9. Patrick Gartung (Fermilab)
10. Tim Brown (NOAA)
11. Mike Collette (LLNL)

Present in spirit

1. Elizabeth Fischer (@citibeth) (NASA-GISS)
2. Massimiliano Culpo (EPFL)

News

1. Spack 1.0 is postponed until end of March.

• travel and other priorities have gotten in the way
  • March is looking much more free!
• progress on SAT solver and testing are being made

1. Greg Becker working on more specific targets

• Allow spack packages to be built at gcc -march granularity
  • i.e., "build for haswell", "build for skylake", "build for power8le"
• also allow users to revert to generic x86_64 (or similar) if they want generic binaries
• Cray targets already do this (thanks to Cray programming environment)

1. Lots of new contributions popping up from teams on the Exascale Computing Project

• many teams interested in collaborating to get their packages into Spack
• next xSDK release will be using Spack

1. Spack being used in ORNL (Billings) "app store" for HPC Eclipse project.

2. setuptools is trying very hard to make itself unpackagable, but there is a good discussion and some hope -- see here

3. Massimiliano: I have a few PRs ready for review (#1167, #1875, #2386, #3125) and a refactoring in progress (#3183)

4. @citibeth: I believe Massimiliano's PRs should be high priority, especially #2386. With that in place, I want to tame the static/shared and debug/release options, starting in CMakeBuild. We've discussed this, but now it needs to be done.

5. @citibeth: #2664 should be prioritized. For one, it's a bugfix: things that should work just don't without it. Also, it involves some refactoring, which makes it susceptible to conflicts with other PRs. Are we waiting for anything more on this, or can it be merged?

6. @citibeth: #3134 needs some review /discussion: @alalazo and I fundamentally disagree on this issue. If I'm going to go forward with this PR, I would like some confirmation on the basic idea and design.

7. Todd: RE: @citibeth and Massimiliano: trying very hard to get to these awesome PR's -- will review and try to merge soon.

Discussion

1. Greg Becker:

• Some systems don't have modulecmd executable present in the PATH
  • doesn't correctly handle lmod
  • Greg has support for using typeset -f in bash
    • still thinking about csh
  • we're trying to dig out some of this support from some older PRs that were closed.

1. Tim Brown submitted a PR to make Ruby extendable in Spack

• having issues with mirroring in the PR
• Tim says it was very easy to make Ruby extensible (yay!)

1. Paul Hopkins (LIGO collaboration)

• submitted a number of PRs that we haven't gotten around to reviewing
  • using Spack to install to CVMFS, which is a RO filesystem CERN uses
  • package hierarchies can get quite deep
  • people are having issues using the installed Python due to deep paths
    • using sbang externally not an option / overly cumbersome
• Paul's PR allows the install path to be changed so that the hash is shorter
  • potential issues:
    • We'll need to take this into account when we integrate binary packaging
      • not only re-RPATH things but also adjust the install location to the new directory layout
    • install layout should probably be a function of the particular package tree
      • spack currently only supports one install root, but we'd like to support multiple (one spack relying on another)
      • description of the install layout should be stored with the particular root, not in config.yaml
      • spack will need to look at description of the install tree to figure out what to do
      • Spack will need to bail out gracefully when there is a hash conflict due to a short install location.
  • issues are not serious; but just want to make sure this is future proof for some other frequently requested features.

1. Peter Scheibel has been working on #2548

• concretize build dependencies separately from others
  • solves problems like:
    • need to build cmake~qt to build qt, which is needed to build cmake+qt
      • similar issues with tcl~X
    • need to build build dependencies for the front-end on cross-compiled machines like BG/Q and Cray
  • adds a separate include dependency type
    • debating whether to separate this from link
    • may solve issues like ones we're having with gettext and libintl
      • no more transitive override of gettext function by libintl headers if we don't include them for transitive deps
  • Will also document dependency types and what they do, specifically.