Telcon: 2022 02 23

Attendees

• Peter Scheibel (host)
• Mark Krentel
• Wileam Phan
• Tammy Dahlgren
• Brian Van Essen
• Massimiliano Culpo
• Greg Becker
• Kacper Kornet

Agenda items

• (Wileam) Treating CUDA as a virtual as provided by nvhpc: https://github.com/spack/spack/pull/29155
  • This revisits the general issue of vendored dependencies: https://github.com/spack/spack/issues/19365
  • Examples (how common is it to vendor dependencies)
    • mvapich2 + hwloc
    • papi + perfmon
    • nhvpc + cuda
  • (Massimiliano)
    • Do we need a "contains" kind of directive?
    • nvhpc -> contains("cuda@11.2")
    • Massimiliano will look into this
• Wileam: ping on https://github.com/spack/spack/issues/9134

For next week

• Packages with multiple build systems
  • e.g. a package changes build systems for some version
  • See also https://github.com/spack/spack/pull/27021/files#diff-a69c213bdd36ddd464aa29f039985532107a6527f68c253fb5f0d204d7b462db
    • i.e. the build system is often different on Windows
  • IMO this is as simple as
    • Have a when-style clause for activating a build_system
    • When the build system is active, look for e.g. cmake_install vs. install
    • Users can just define install if they only use one build system
  • (Massimiliano) There are SEPs pending on this subject https://github.com/spack/seps/pull/3 and https://github.com/spack/seps/issues/4
• A spack update command
  • See https://github.com/spack/spack/issues/9134
    • The original request is to update the core/package-repo without actually installing/reconcretizing
    • There is at least one comment in there additionally requesting that such a command would update your installed packages: https://github.com/spack/spack/issues/9134#issuecomment-731296808
  • The overall idea is that users can update their Spack instance but this generally takes several commands
    • If there is a common pattern, then spack update could replace several steps with just one call
    • The issue's initial description describes a simple common pattern but has a couple of side cases worth investigating:
      • If you are on the develop branch, pull the latest state
        • If you are on another branch, fail
        • Or... try merging from develop into the branch after pulling it?
      • If you have existing changes stash and reapply them
        • If the reapply fails, then revert the fetch (i.e. return to the commit you were at before spack update
        • What if the reapply succeeds, but the resulting logic is broken? Should there be an undo?

Possible agenda items

• (Peter) Externals cut off dependencies: https://github.com/spack/spack/issues/9149#issuecomment-1020740273
• (Peter) Automating xcompiler for options that ought to be fed to underlying compiler for nvcc:
  • See: https://github.com/spack/spack/pull/28769#pullrequestreview-880622801
• Possible topic: Separating package repository from core
  • There are some larger changes we plan which mean we can't do this immediately
  • But we could record what is in the way and how to manage this transition
• Possible topic: new concretizer and handling of merged package repositories
  • See also: https://github.com/spack/spack/issues/28259