diff options
| author | Todd Gamblin <tgamblin@llnl.gov> | 2021-08-08 12:42:45 -0700 |
|---|---|---|
| committer | Todd Gamblin <tgamblin@llnl.gov> | 2021-11-05 00:15:47 -0700 |
| commit | 40b914503e2441c0f51de737e3901f8f546ccbce (patch) | |
| tree | 959c01ce501daf1af28a9b18924923245cfda2b4 /.dockerignore | |
| parent | 2c142f9dd4cf29220f6b2840f4d448c5c9d936f1 (diff) | |
| download | spack-40b914503e2441c0f51de737e3901f8f546ccbce.tar.gz spack-40b914503e2441c0f51de737e3901f8f546ccbce.tar.bz2 spack-40b914503e2441c0f51de737e3901f8f546ccbce.tar.xz spack-40b914503e2441c0f51de737e3901f8f546ccbce.zip | |
concretizer: adjust integrity constraints to only apply to builds.
Many of the integrity constraints in the concretizer are there to restrict how solves are done, but
they ignore that past solves may have had different initial conditions. For example, for things
we're building, we want the allowed variants to be restricted to those currently in Spack packages,
but if we are reusing a concrete spec, we need to be flexible about names that may have existed in
old packages.
Similarly, restrictions around compatibility of OS's, compiler versions, compiler OS support, etc.
are really only about what is supported by the *current* set of compilers/build tools known to
Spack, not about what we may get from concrete specs.
- [x] restrict certain integrity constraints to only apply to packages that we need to build, and
omit concrete specs from consideration.
Diffstat (limited to '.dockerignore')
0 files changed, 0 insertions, 0 deletions