When spack-manager was initially created the goal was to have a single set of configurations per physical machine. Broader surveying of the user community shows that users also like to partition configs on toolchains or other attributes.
The term "machine" is really a misnomer in this case, and rather it is a context for included configurations. Change the name, and options. Also consider how to filter nested contexts such as:
configs
| machine_a
| _ gcc
| _ clang
| machine_b
| _ gcc
| _ clang
In this case, we would want to detect the "machine" level context, but still require selection of the gcc or clang context.
Another model we could endorse would look like this
configs
| sys
| _ machine_a
| _ _ gcc
| _ _ clang
| _ machine_b
| _ _ gcc
| _ _ clang
| usr
| _ machine_a_gcc
| _ machine_b_gcc
... etc
So perhaps we need to consider ways for users to specify their layout and detection depth mechanisms.
When spack-manager was initially created the goal was to have a single set of configurations per physical machine. Broader surveying of the user community shows that users also like to partition configs on toolchains or other attributes.
The term "machine" is really a misnomer in this case, and rather it is a context for included configurations. Change the name, and options. Also consider how to filter nested contexts such as:
In this case, we would want to detect the "machine" level context, but still require selection of the
gccorclangcontext.Another model we could endorse would look like this
So perhaps we need to consider ways for users to specify their layout and detection depth mechanisms.