b88da9d73d
Minimizing builds is tricky. We want a minimizing criterion because we want to reuse the avaialble installs, but we also want things that have to be built to stick to *default preferences* from the package and from the user. We therefore treat built specs differently and apply a different set of optimization criteria to them. Spack's *first* priority is to reuse what it can, but if it builds something, the built specs will respect defaults and preferences. This is implemented by bumping the priority of optimization criteria for built specs -- so that they take precedence over the otherwise topmost-priority criterion to reuse what is installed. The scheme relies on all of our optimization criteria being minimizations. That is, we need the case where all specs are reused to be better than any built spec could be. Basically, if nothing is built, all the build criteria are zero (the best possible) and the number of built packages dominates. If something *has* to be built, it must be strictly worse than full reuse, because: 1. it increases the number of built specs 2. it must have either zero or some positive number for all criteria Our optimziation criteria effectively sum into two buckets at once to accomplish this. We use a `build_priority()` number to shift the priority of optimization criteria for built specs higher. |
||
---|---|---|
.. | ||
spack |