In late night conversation last night Darius and I were made aware of this tool which some national labs are using to deal the platform configuration issue:
The tooling has a ‘simple’ json config file for establishing all the variants of a platform including the ability to build and install multiple compilers and libraries (aka beman or boost) onto the same machine in an orderly way (apparently it has in internal constraint propagation capability to figure out all the dependencies). There’s a cppcast discussion from 2021 (I don’t have time to listen right now) where the developers are interviewed.
The big weakness for us is that there doesn’t appear to be windows support. Still it might be worth it for just rich support of Linux and MacOS. Also, if they’ve figured out the ‘options’/‘config file’ problem we could certainly learn from that.
If someone has time to experiment and report back that would be cool. @river this seems exactly like the sort of tool we should consider for maintaining the dev images.
${DAYJOB} is a major Spack contributor and maintainer.
If you’re not building software for HPC there’s little reason to use Spack as your primary development package manager. It is designed around the needs of that community, specifically with regards to holistic toolchain management.
HPC cares a lot about problems like “How do I make sure my Fortran compiler is ABI compatible with my ${NICHE_VENDOR} C++ compiler?” Spack has infrastructure for managing a wider variety of tooling concerns than “I need you to get that source code from over there” which is what most language-level package managers deal with.
This makes Spack unwieldy for the median C++ project which needs like, Catch2 and maybe some parts of Boost, and “I like my compiler just how it is thanks Spack”.
It’s weaker than container matrices for testing, there was some effort put into letting Spack really build/manage an entire platform (See: self-hosted spack, or container spackOS by trws · Pull Request #42082 · spack/spack · GitHub). This is necessary if you actually want to test on different libc’s, but a Spack-built libc doesn’t really tell you anything about how your program runs on Ubuntu or MacOS 15, to test on those you need to well, test on them.
So all roads lead back to container matrices, at which point just put the compiler in the container and you’re already done.