Telcon: 2015 04 30

April 30, 2015 Spack telcon

9am, Pacific Time.

Participants

• Todd Gamblin, LLNL
• Mike Collette, LLNL
• Jim Galarowicz, Krell Institute
• Matt Legendre, LLNL
• Greg Lee, LLNL
• Adam Moody, LLNL
• Malcolm Cook, Stowers Institute for Medical Research

Agenda

1. Spack news:

• Intel is looking at using Spack for their Open Community Runtime
• Spack being used by LLNL production code team members
• Spack has a Roadmap
• Spack has a Google Group, with lots of traffic!

1. Upcoming Contributions:

• XL support: Francois Bissey (Canterbury)
• Symlink Views: Matt Legendre (LLNL)
• External package repos: Matt Legendre (LLNL)

1. New spack diy command: do-it-yourself build in a directory

2. Declared variants:

class Mpich(Package):
    variant('debug', default=False, description="Compile MPICH in debug mode")

Above code allows packages to check variants.

1. Variants, concretization, and specs

• During concretization, a spec without variants (e.g., mpich) means "don't care".
• After concretization, a spec without a particular variant means "don't know", as that wasn't part of the spec.

1. Progress on reworking directory structure and on-disk spec format

• Default directory layout will now contain no @, ~, +, or other special chars:

  <install root>/
      <architecture>/
         <compiler>-<compiler version>/
             <name>-<version>-<variants>-<hash>
  

• New format will not work with old format

  • Need to rebuild old packages to use new spack -- hopefully the last time.

• develop no longer compatible with master

1. Config file format moving to YAML

• Config will go in ~/.spack/config.yaml
• Also in $spack_prefix/etc/spack/config.yaml (still hierarchical like before)
• Compilers currently stupidly associated with one architecture
  • New config will associate compilers with arch they were detected on
• News from the mailing list on compiler flags (ability to supply compiler runtime RPATHs)

1. Compiler flags

• Need better features for specifying compiler flags for particular packages
• Working on a config format for this.
  • New config file format in YAML should help a lot.
• Working on ways to set this per compiler and per package within some kind of "profile"

1. Better support for modules.

• Much discussion with Malcolm Cook about how he'd like modules supported.

6. Questions, comments, and updates:

• Mike playing around with getting his code up on linux
  • working on making dummy packages that specify the dependencies and specific versions.
    • dummy packages ensure that the entire stack has a consistent DAG.
  • needs a proper profile
  • some packages need customizations
    • some are pretty specific to particular libraries
  • Mike created his own compiler definitions
    • needs to be factored out into a high-level arch description
• Malcolm is interested in generating modules
  • Wants to inject a run-time version of depends_on
  • Modules community is debating a lot about whether loading one module should force unload/load dependencies
  • Need new dependency relationships:
    • depends_build()
    • depends_run()
  • If we had these we could generate modules correctly.