From 9c5c327a6feb47528b01029806477e84073a3a13 Mon Sep 17 00:00:00 2001 From: Todd Gamblin Date: Thu, 3 Nov 2022 17:26:03 -0700 Subject: propagation: don't count propagated variant values as non-default (#33687) 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. --- lib/spack/spack/solver/concretize.lp | 2 ++ 1 file changed, 2 insertions(+) (limited to 'lib') diff --git a/lib/spack/spack/solver/concretize.lp b/lib/spack/spack/solver/concretize.lp index 2bbf3091c6..02528e694d 100644 --- a/lib/spack/spack/solver/concretize.lp +++ b/lib/spack/spack/solver/concretize.lp @@ -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 -- cgit v1.2.3-60-g2f50