diff options
| author | Vanessasaurus <814322+vsoch@users.noreply.github.com> | 2021-03-14 13:00:15 -0600 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-03-14 19:00:15 +0000 |
| commit | 6ff717f39583a56be427bb04bf53bf304d74c534 (patch) | |
| tree | 65e3a38011d869f77af9bde6120ea4ca9cbfce1b /var | |
| parent | d22bad13b114e08ed611ede29b2f06eb4311c827 (diff) | |
| download | spack-6ff717f39583a56be427bb04bf53bf304d74c534.tar.gz spack-6ff717f39583a56be427bb04bf53bf304d74c534.tar.bz2 spack-6ff717f39583a56be427bb04bf53bf304d74c534.tar.xz spack-6ff717f39583a56be427bb04bf53bf304d74c534.zip | |
do not validate variants of concrete specs in solver setup (#22272)
Currently, regardless of a spec being concrete or not, we validate its variants in `spec_clauses` (part of `SpackSolverSetup`).
This PR skips the check if the spec is concrete.
The reason we want to do this is so that the solver setup class (really, `spec_clauses`) can be used for cases when we just want the logic statements / facts (is that what they are called?) and we don't need to re-validate an already concrete spec. We can't change existing concrete specs, and we have to be able to handle them *even if they violate constraints in the current spack*. This happens in practice if we are doing the validation for a spec produced by a different spack install.
Signed-off-by: vsoch <vsoch@users.noreply.github.com>
Diffstat (limited to 'var')
0 files changed, 0 insertions, 0 deletions