Telcon: 2022 03 09

Attendees

• Peter Scheibel (host)
• Mark Krentel
• Wileam Phan
• Gregory Becker
• Jared Popelar
• Richarda Butler
• Massimiliano Culpo
• Stephen Sachs

Agenda items

• (Mark) ROCm Spack support

  • How often do people install with Spack vs. using an external
  • Has some PRs that should enable the Spack-only install to work
    • (although there has to be a download of kernel drivers, so there may not be much advantage in handling part of the install through Spack)
  • Should testing of the ROCm packages be done in a CI process?

• 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

  • From meeting:

    • (Wileam) If we only choose one build system, what about packages that offer an option to build with either?
      • Choosing one seems to work OK (that has worked up to now)
    • Note that dyninst (https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dyninst/package.py) which defines a different cmake_args for different versions (because the CMake option names change) wouldn't be simplified by this
    • (Peter) Should the build_system declaration have a phases arg?
      • (Max) no: the phases are implied by the choice of build system
        • what about defining arbitrary phases?
          • run_after could be used to "insert"
          • It would have to designate the build system though if you have a CMake build and an Autotools
          • run_after(build) -> @cmake.run_after(build)
          • run_after(build, cmake)?
    • Is it possible to do this in a way that doesn't force existing packages to switch immediately?
    • Part of this imposes a variant for "build_system"
      • (this isn't clear from the SEP)
      • All packages would have this implied variant
        • This would change all the hashes
        • The reuse concretizer should be able to make use of the old installs
        • (Greg) Although could possibly be handled in a manner similar to compiler flags
    • (Max) This would also potentially result in some changes to the constraints defined for the concretization
      • (Peter) e.g. if you can choose between autotools and cmake, how do you prefer cmake?
      • (Peter) and also whichever build system was used is arguably part of the identity of the package

• (Greg and Wileam) Proposal for nvhpc vendoring CUDA: can we delete the vendored CUDA?