Skip to content
Todd Gamblin edited this page Apr 19, 2018 · 15 revisions

Attendees

  • Todd Gamblin (LLNL)
  • Dan Topa (LANL)
  • Patrick Gartung (Fermi)
  • Peter Scheibel (LLNL)
  • Mario Melara (NERSC)

News

  • Static/shared library variant updates

    • Peter Scheibel will be experimenting with a multi-valued variant convention for this.
    • possible values: (shared), (static), or (shared, static).
    • omitting static-pic for now, but this scheme leaves room for that if we want it later
    • also allows packages to declare which values they allow
  • ECP, continuous integration, and release process updates

PRs of interest:

Issues

  • Dan: can't get clang in core for lmod module config
  • Patrick:

Discussion

  • Peter: Static/shared:
    • There should be a single-valued variant called "linktype" with the values "shared", "static", and "both"
      • Most packages would default to "shared"
      • This is better than a multi-valued variant because for example if a package supports only building shared XOR static then the allowed values could omit "both"
    • Packages should be individually edited to include a linktype variant (because some packages don't build any libs/executables and are just scripts)
    • Some packages may only build static, or only shared, and in that case a linktype variant still makes sense (mainly to keep track of dependency relationships) but e.g. it would only ever be one value
    • Generally, this variant is anticipated to dictate both the objects that are created, and how they are linked.
      • E.g. linktype=shared means "build shared objects and link them against shared libraries"
      • Which is to say that concretization should generally propagate shared/static to dependencies with the "link" deptype

Dan:

  • don't use modules much at LANL but trying to bring them in
  • really liking the Lmod configuration in Spack
  • will try to push on the HPC team to use Lmod in production.
Clone this wiki locally