Telcon: 2021 10 06
- 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
-
(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
, andspack env activate
-
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: shouldsetup_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
- This would make Spack modules work like
-
Harmen: what is the difference between link/run dependencies
- See also: https://github.com/spack/spack/issues/3768
- See also: https://github.com/spack/spack/pull/18365
- Tammy: should we always be installing test dependencies (for running tests after install)
- Greg: keep them abstract?
- And then concretize them at test time (reusing dependencies)
- See also: https://github.com/spack/spack/pull/18365
- See also: https://github.com/spack/spack/issues/3768
-
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
- Greg: Spack creates its own modules for externals
-
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)
- It would help to have access to multiple sets of compilers for one build
- 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)
- 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)
-
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).
- This has been observed with dependencies such as
- TBC next week
- If you concretize at test time (vs. build time) then this depends on reuse in the concretizer
- If not, there a potential issue with inconsistent test dependencies used to run tests at build time versus those used for stand-alone tests.
-
Discussion: Packages which require multiple build systems: how to handle them?
- Discussions on this:
- (Proposal based on using a new directive) https://github.com/spack/seps/blob/8dafadb4cae08275d168af964b3d168b4248977f/seps/sep-0002.md
- (Notes on trying an approach based on a
when
class decorator) https://github.com/spack/seps/issues/4
- Two approaches were covered: Greg thought there were issues with both; we will cover that this week.
- Discussions on this:
-
Discussion: long environment activations - are you having an issue with this?
- Some large envs might have this problem, e.g.: https://github.com/spack/spack/issues/25555