summaryrefslogtreecommitdiff
path: root/share
diff options
context:
space:
mode:
authorTodd Gamblin <tgamblin@llnl.gov>2020-12-15 11:58:58 -0800
committerTamara Dahlgren <dahlgren1@llnl.gov>2021-02-17 17:07:26 -0800
commit12d035b225f31e128e9cd9353ed70e4a784ebe0a (patch)
treedeb53527354640cc4e525c2e31853a47d36a5eeb /share
parentbf3a873a42728d0ff4c90232c6a446574db7bc25 (diff)
downloadspack-12d035b225f31e128e9cd9353ed70e4a784ebe0a.tar.gz
spack-12d035b225f31e128e9cd9353ed70e4a784ebe0a.tar.bz2
spack-12d035b225f31e128e9cd9353ed70e4a784ebe0a.tar.xz
spack-12d035b225f31e128e9cd9353ed70e4a784ebe0a.zip
concretizer: don't use one_of_iff for range constraints (#20383)
Currently, version range constraints, compiler version range constraints, and target range constraints are implemented by generating ground rules from `asp.py`, via `one_of_iff()`. The rules look like this: ``` version_satisfies("python", "2.6:") :- 1 { version("python", "2.4"); ... } 1. 1 { version("python", "2.4"); ... } 1. :- version_satisfies("python", "2.6:"). ``` So, `version_satisfies(Package, Constraint)` is true if and only if the package is assigned a version that satisfies the constraint. We precompute the set of known versions that satisfy the constraint, and generate the rule in `SpackSolverSetup`. We shouldn't need to generate already-ground rules for this. Rather, we should leave it to the grounder to do the grounding, and generate facts so that the constraint semantics can be defined in `concretize.lp`. We can replace rules like the ones above with facts like this: ``` version_satisfies("python", "2.6:", "2.4") ``` And ground them in `concretize.lp` with rules like this: ``` 1 { version(Package, Version) : version_satisfies(Package, Constraint, Version) } 1 :- version_satisfies(Package, Constraint). version_satisfies(Package, Constraint) :- version(Package, Version), version_satisfies(Package, Constraint, Version). ``` The top rule is the same as before. It makes conditional dependencies and other places where version constraints are used work properly. Note that we do not need the cardinality constraint for the second rule -- we already have rules saying there can be only one version assigned to a package, so we can just infer from `version/2` `version_satisfies/3`. This form is also safe for grounding -- If we used the original form we'd have unsafe variables like `Constraint` and `Package` -- the original form only really worked when specified as ground to begin with. - [x] use facts instead of generating rules for package version constraints - [x] use facts instead of generating rules for compiler version constraints - [x] use facts instead of generating rules for target range constraints - [x] remove `one_of_iff()` and `iff()` as they're no longer needed
Diffstat (limited to 'share')
0 files changed, 0 insertions, 0 deletions