Skip to content

Telcon: 2016 03 17

Jump to bottom Edit New page
Adam J. Stewart edited this page Mar 17, 2016 · 18 revisions

Participants

  1. Todd Gamblin (LLNL)
  2. Patrick Gartung (Fermilab)
  3. Ben Boeckel (Kitware)
  4. D'jay Deo (Kotware)
  5. Jim Galarowicz (Krell)
  6. Greg Becker (LLNL)
  7. Peter Scheibel (LLNL)
  8. Elizabeth Fischer (NASA)
  9. John Gash (LLNL)
  10. Brandon (NERSC)

News

  1. As usual, lots of contributions, see the pulse
  • Github stats show over 7k views, 276 unique visitors in 2 weeks (getting busier)
  1. A number of issues with #120 have been fixed
  • Better concretization has been merged #549
    • Spack will do a more comprehensive search to find virtual that satisfy a spec without conflict
  • Others: #531, #532
  1. New feature: sanity check paths
  • prevent badly behaved builds from succeeding incorrectly
  1. PR #552 from Massimiliano Culpo (EPFL) adds enhanced module support (still WIP, expect it to be merged in soon)
  • Refactors setup_dependent_environment into several functions
  • Intent is to unify env setup inside and outside Spack
    • packager says what needs to be in the env, spack uses it to set up dependent environment before build and to generate modules.
    • extendable packages like Python can set some default env module settings for their extensions.
  1. PR #378 Dependency types looks nearly done.
  • Needs integration with PR #120 (externals)
  1. PR #561 being integrated by Greg Becker right now.
  • This PR includes:
    • Cray support
      • finding compilers from modules in addition to paths
    • New architecture support
      • platform - OS - target
      • platforms have compiler finding strategies
  • Will be in soon, as well.
  • Will likely cut a release before merging to develop as this changes config files.

  1. Adam Stewart submitted WIP: PR #558 for Installing PGI compilers

  2. Patrick Gartung asked how to use mpicc in Spack builds -- good question

  • Will explain and document this better.
  1. @citibeth has put in WIP: PR #543
  • Splits install into configure, build, install
  • Also adds a spconfig command that generates a script that can be used to configure a project as Spack would, but from outside spack.
  • This makes it easier to build external projects that depend on Spack
    • particularly CMake ones
  • feedback welcome!

Issues

  1. Patrick has issues with spack detecting homebrew's gcc 4.9.3
  2. Ongoing issues at some sites w/getting Intel compilers working properly.
  • Would like to take a more detailed look at this once PR #561 (OS/platform/better compiler support) is merged
  • Will allow sourcing intel env setup in Spack's cc
  1. Lots of issues filed related to picking the proper version of things.
  • Disabling/upgrading versions for security.
  • Installing release candidates vs stable versions
  • packages.yaml can help with this! See docs on concretization policies
  • more detailed ideas below for how to manage this going forward.
  1. Issues/missing features with #120 still to be fixed

Discussion

  1. Want to manage concretization policies better.

  • Many levels of preferences:

    • Default Spack stack (defaults)
    • Site (spack repo) specific settings
    • user-specific settings
    • what is already installed

  • Proposal: Hierarchy of packages.yaml files, in precedence order (low to high)

    1. Preferences in package.py files: all versions, optional preferred/blacklist keywords
    2. $spack/etc/spack/defaults/packages.yaml: built in spack stack, upgraded over time.
    3. $spack/etc/spack/defaults/$platform/packages.yaml: specialized overrides of builtin stack, per-platform
    4. $spack/etc/spack/site/packages.yaml: allow to override defaults by site or repo
    5. $spack/etc/spack/site/$platform/packages.yaml: arch-specific overrides per site.
    6. Whatever is currently installed.
    7. ~/.spack/packages.yaml: user can override site and other settings.
    8. ~/.spack/$platform/packages.yaml: arch-specific user settings.

  • Could make the precedence customizable, e.g., config setting like this:

        precedence: package, default, site, installed, user

  • Should have option to ignore installed packages entirely if desired.

    • Allows users to force an install to snap to the current config settings.

  • Concretization based on what is already installed keeps the local environment stable.

    • Need a mechanism to spack update or similar, to get to the latest version
      • potentially graft old installs to newer ones by symlinking them, esp. for security updates.
    • Need a mechanism for spack update blacklisted to just get security patches.
    • See Guix grafts - we'd like something similar but using symlinks to prefixes.
  1. Comments/Discussion on StagedPackage? https://github.com/LLNL/spack/pull/543
Add a custom footer
Clone this wiki locally