Should spack be more aggressive about reusing dependencies?

[HadrienG2]

Currently, if a build of a package with non-default variants is available, spack will not use it when building a package which has a compatible depends_on spec. Instead, it will do a build of the default variant of the dependency, unless explicitly asked to do otherwise in the "spack install" spec.

I think that spack should look for installed packages with a spec matching a depends_on() statement before resorting to building a new version of the dependency.

[alalazo]

Duplicate of #311

[HadrienG2]

Nice catch! I did not find the right keywords to search for this one.

[alalazo]

As far as I understand, not specifying variants of a dependent package in a depends_on statement currently means "I depend on the default variants of this package". I think this should mean "I do not care about the unspecified variants" instead.

I think this part is incorrect. The depends_on directive in a package recipe behaves like you want: an unspecified variant can already accept any valid value. The fact that Spack is not reusing software that has already been installed stems from the concretization algorithm. Currently this algorithm is deterministic, in the sense that any variant you don't specify on the command line and whose value is not "prescribed" by constraints in the depends_on directives, will be resolved to its default value.

As far as I know @tgamblin is working on a new concretizer algorithm that does exactly what you ask.