Telcon: 2017 04 20

Participants

1. Kiel Friedt (LLNL)
2. Ben Boeckel (KitWare)
3. Christoph Junghans (LANL)
4. Ben Casses (LLNL)
5. Peter Scheibel (Host)
6. Steve Leak (NERSC)

News

1. Draft GPG binary signing PR by Ben Boeckel (https://github.com/LLNL/spack/pull/3845)

   • Straw man of UI so far; no logic yet. EDIT: now updated as of Yesterday (4/19). A gpg command is available: spack gpg sign <file>
   • Spack keeps a keyring, you can add keys. Right now if there are multiple one cannot choose between them, one is chosen by default.
   • Will allow binary packaging work to be merged when done (https://github.com/LLNL/spack/pull/445)

2. Kiel Friedt at LLNL has been finishing up the test-suite command. Format (https://github.com/LLNL/spack/pull/2917) reworked to include arbitrary spec lists, and cartesian products of them:

#
# This YAML file describes a Spack test suite
#
test-suite:
    # Build matrix.  Spack takes the cartesian product of each dimension
    # in this section to define a set of specs to build.
    # This one is just a list of specs.
    matrix:
      specs:
      - abinit@8.8.8b
      - ack@2.14
      - etc.

or, a more complicated example with multiple types of spec lists multiplied by each other:

#
# This YAML file describes a Spack test suite
#
test-suite:
    #
    # Optional include/exclude spec lists and upload information.
    #

    # Only specs that match a spec in this list will be included in
    # the tests.  If include is missing, all specs are built.
    include: [bzip2, libelf, libdwarf]

    # Specs that match a spec in this list are excluded.
    # If exclude is missing or empty, all included packages are built.
    exclude: []

    # URL of the cdash server where results should be submitted.
    # Optional. Defaults to https://spack.io/cdash
    - cdash: ["https://spack.io/cdash"]

    # Project on the cdash server where results should be submitted.
    # Optional. Defaults to 'spack'.
    - project: spack

    # Build matrix.  Spack takes the cartesian product of each dimension
    # in this section to define a set of specs to build.
    matrix:
      # List of packages, each with a set of versions to test.
      - packages:
          abinit:
            versions: [8.0.8b]
          ack:
            versions: [2.14]

      # List of compiler versions. Each package is tested with all
      # compiler versions.
      - compilers:
          gcc:
            versions: [4.9.0, 4.7.1, 4.6.3, 4.6.1]
          clang:
            versions: [7.3.0, 3.4, 3.1]

      # build everything with mpich and with openmpi
      - specs: [^mpich ^openmpi]

      # also build everything with and without shared libs enabled.
      - specs: [+shared ~shared]

(EDIT scheibelp) A user can specify multiple matrices by creating multiple files.

• Peter Scheibel is working on a straw man first design for environments

  • Pretty close to having a concrete suggestion
  • First get https://github.com/LLNL/spack/pull/3227 merged
  • Then allow packages to dictate how they should be merged into views (similar to activate) - e.g. python copies the python executable vs. symlinking so you can use pip with it
  • Then allow user to declare environments, which consist of: a view (i.e. created by the view command), a set of frozen packages
  • A user may declare an environment when doing spack install which has two effects:
    • Newly-installed packages are added to frozen packages
    • Frozen packages are used to concretize (essentially they are treated like external packages with buildable=False)
  • Together this should allow a user to maintain a familiar layout and also avoid reinstalling large dependency trees when they just want to add a python module etc.

• Greg Becker working on some changes to compiler flags

  • current compiler flag work injects flags in the compiler

• Adam Stewart and Denis Davydov reworking filtering of system paths from builds management of system paths in builds

  • https://github.com/LLNL/spack/pull/3910
  • This PR ensures that Spack never adds system paths to any environment variable (previously it may do this e.g. when an external package is located in a system path)
  • System paths can show up in PATH, but they always appear after paths added by Spack (see the PR for more details)

• (EDIT scheibelp) Adam Stewart: https://github.com/LLNL/spack/pull/3866

  • Perl, Python, and R packages are no longer (build, link) deptype by default, they are (build, run)
  • This will have an effect when https://github.com/LLNL/spack/pull/3347 gets merged (where run dependencies of build dependencies are added to PATH for a build)
  • And by the way: https://github.com/LLNL/spack/issues/3768 is a place to discuss deptypes and their intended effects on builds (i.e. what gets RPATH'ed, what gets added to PATH during a build, what gets added to PATH at runtime etc.)