-
Notifications
You must be signed in to change notification settings - Fork 4
Long term plans
Marc Mengel edited this page May 21, 2024
·
6 revisions
I think it makes sense to replace this current body of shell scripts with:
- spack extensions so that they become spack commands
- config files for:
- our preferred packages.yaml and
- mirrors/buildcaches
- and finally, roll all these into the fermi spack branches, pref. as submodules
Thus a git clone --recursive of our fermi spack repository would implicitly include all of our extensions and config files from the repositories.
More specifically git submodules under:
- etc/spack/linux with packages.yaml, bootstrap.yaml, config.yaml updates per os
- var/spack/repos (one each) for all of our current recipe repositories
- var/spack/extensions (one each) with our spack extensions (listed in config.yaml, above)
Then a git clone --recursive of our fermi spack with those submodules will be pretty much configured out of the box.
Extensions wanted:
- linuxexternals -- already rough-drafted, is make_packages_yaml as a spack exension
- subspack -- make sub-spack as a spack extension (draft started)
- build_env -- build_spack_env.sh as a spack extension
- env_buildcache -- make buildcache from packages a) in an environment and b) optionally (--local? ) local to this spack (not upstream)
- Some tool for distributing environments via buildcache:
- sync_buildcache -- some combination of the buildcache scripts in bin currently(?)
- spack extension pair for publishing /installing an environment to/from a build cache -- it would buildcache create the packages locally, upload them, and also upload the spack.lock/spack.yaml to some uploaded_envionment directory on the publish, and fetch the spack.{lock,yaml} and create the environment on the install (and optionally install any missing build dependencies?) It could maybe also deal with a tarball on Jenkins or similar?