Skip to content
Peter Scheibel edited this page Oct 11, 2021 · 18 revisions

Attendees

  • Peter Scheibel
  • Greg Becker
  • Mark Krentel
  • Gregory Becker
  • Harmen Stoppels
  • Kacper Kornet
  • Marty Kandes (SDSC)
  • Massimiliano Culpo
  • Phil Sakievich
  • Tammy Dahlgren
  • Zhi-Qiang You
  • Kayla Butler

Agenda

  • (Suggestion for next week) Greg/Harmen: versions https://github.com/spack/spack/discussions/26557

  • (Suggestion for next week) Phil Sakievich: spack develop questions about direction

  • Resolving discrepancies between spack load, module load, and spack env activate

    • See: https://github.com/spack/spack/discussions/26266

    • Discussion point: Greg pointed out that some link-type deps require env variables to be set (MY_CONFIG_FILE=/path/to/path.ini or so). This implies calling setup_run_environment on that dep. One solution is to make the dependent add a (run, link)-edge instead of just link edge, but it doesn't seem like it's the dependent's responsibility. So: should setup_run_environment be called on each transitive link type dep too (and run type deps of link type deps)? What is the difference between link/run type deps then, really? Just that only-link-type deps prefix paths aren't added to PATH?

    • Autoloading modules by default?

      • This would make Spack modules work like spack load
    • Harmen: what is the difference between link/run dependencies

    • Greg: the modules we generate have to work if loaded directly or transitively

      • spack load could differentiate between loading roots and loading dependencies
        • However, it collects specs upfront so essentially loads each as a root (but is that intentional)?
    • Greg: lmod and TCL 4 may both support reference counting when it comes to loading dependencies

      • It would be good to add this if autoloading by default
      • Let's say you load mpich, and unload it, then all the dependency modules are not unloaded
      • Massimiliano: if you load two things with the same dep, and then unload each along with deps, then without reference counting
  • Harmen: do we autoload external modules?

    • Greg: Spack creates its own modules for externals
      • Greg: We should probably explicitly load the system-provided module
      • This is hard to integrate with the existing lmod hierarchy
        • Massimiliano: some of the difficulty is related to the naming conventions used in the lmod hierarchy
      • This might be easier for TCL modules
  • Harmen: when you swap between Cray programming envs, is there a way to automatically change the config?

    • https://github.com/spack/spack/pull/26341
    • Related: if we use env variables to control user/system scopes, then this also offers an option to "avoid" using a scope
      • Todd apparently had objections to prior PRs that do this
  • Cray cross-compiling issues (we touched on this during the meeting)

    • Mark: main source of issues on Cray is the frontend/backend distinction (for their tool, some must be compiled on FE, and some on the BE)
      • It would help to have access to multiple sets of compilers for one build
        • This only works when the FE/BE architectures are "similar enough"
      • Greg: similar issue on Fugaku (desire to build dependencies twice: once for FE and once for BE)
    • Greg: we're a couple features away from working on this
      • Separate concretization of build deps
      • Compilers as dependencies
      • Once those are done, cross-compile support is easier (build/run split across FE/BE)
  • Tammy: should we build (and retain) the test dependencies at concretization/build time, especially if --test is used?

    • If not, there a potential issue with inconsistent test dependencies used to run tests at build time versus those used for stand-alone tests.
      • This has been observed with dependencies such as CMake (versions).
    • TBC next week
    • If you concretize at test time (vs. build time) then this depends on reuse in the concretizer
  • Discussion: Packages which require multiple build systems: how to handle them?

  • Discussion: long environment activations - are you having an issue with this?

Clone this wiki locally