zhangyiss/spack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

propagation: don't count propagated variant values as non-default (#33687)

Browse Source 
We try to avoid non-default variant values in the concretizer, but this doesn't make
sense for variants forced to take some non-default value by variant propagation.
Counting this as a penalty effectively biases the concretizer for small specs dependency
graphs -- something we try very hard to avoid elsewhere because it can lead to very
strange decisions.

Example: with the penalty, `spack spec hdf5` will choose the default `openmpi` as its
`mpi` provider, but `spack spec hdf5 ~~shared` will choose `mpich` because it has to set
fewer non-default variant values because `mpich`'s DAG is smaller. That's not a good
reason to prefer a non-default virtual provider.

To fix this, if the user explicitly requests a non-default value to be propagated, there
shouldn't be a penalty. Variant values set on the CLI already don't count as default; we
just need to extend that to propagated values.
This commit is contained in:
Todd Gamblin 2022-11-03 17:26:03 -07:00 committed by GitHub
parent 79fcc0848f
commit 9c5c327a6f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
lib/spack/spack/solver/concretize.lp
View File

@ -673,6 +673,8 @@ variant_not_default(Package, Variant, Value)
not variant_default_value(Package, Variant, Value),
% variants set explicitly on the CLI don't count as non-default
not variant_set(Package, Variant, Value),
% variant values forced by propagation don't count as non-default
not variant_propagate(Package, Variant, Value, _),
% variants set on externals that we could use don't count as non-default
% this makes spack prefer to use an external over rebuilding with the
% default configuration