I'll give my final thoughts on this, because I knew it was political, and there's already tons of traction in *Spack*:
On Thu, Apr 04, 2019 at 01:51:58AM +0000, Francois Bissey wrote: > Gentoo prefix is awesome but some areas are not as flexible as spack. > Mainly because it is designed like a gentoo distro as a single tree > install. Everything goes into one prefix. So, what *could* have happened was that the HPC community did due diligence, and said, "hmm, what's this portage thing? it's like BSD ports, etc." and extended it for the HPC use cases. What I see time and time again, is that the HPC community reinvents something that exists rather than joining an existing community and making it better. Why do they isolate themselves? I won't go into my suspected reasons, but it's stupid, because there's so much "not invented here" problems that go on in supercomputing. Also, I think portage *can* fill all of the use cases of *Spack*, but it's not done in the way *Spack* presents it. I personally think that providing build configuration on the command line is a bad way to do it, like *Spack* does, and it should be encoded in overlays and/or site specific portage configuration files. Though, I don't know if there's something equivalent to *make.conf*, et al., I don't know Spack well enough. Also, yes, I get that multi-compiler issues that we have in HPC is a strange requirement that we have, but again, *portage* could have solved it if the HPC community had contributed -- and I don't think it's impossible with current *portage*. I do realize you can't use *Prefix* out of the box with the existing *portage* tree. I haven't given it a ton of thought of how to solve it, but we ought to be doing static linking anwyays, because shared linking is hell in a supercomputer center for all of the aforementioned reasons of needing lots of different user requirements. So, I can't turn back time and tell the *Spack* team to go and use *portage*, because it exists now, and it has a lot of traction, but I am going to say it was a stupid decision.
