e20c05fcdf
* Allow branching out of the "generic build" unification set For cases like the one in https://github.com/spack/spack/pull/39661 we need to relax rules on unification sets. The issue is that, right now, nodes in the "generic build" unification set are unified together with their build dependencies. This was done out of caution to avoid the risk of circular dependencies, which would ultimately cause a very slow solve. For build-tools like Cython, however, the build dependencies is masked by a long chain of "build, run" dependencies that belong in the "generic build" unification space. To allow splitting on cases like this, we relax the rule disallowing branching out of the "generic build" unification set. * Fix issue with pure build virtual dependencies Pure build virtual dependencies were not accounted properly in the list of possible virtuals. This caused some facts connecting virtuals to the corresponding providers to not be emitted, and in the end lead to unsat problems. * Fixed a few issues in packages py-gevent: restore dependency on py-cython@3 jsoncpp: fix typo in build dependency ecp-data-vis-sdk: update spack.yaml and cmake recipe py-statsmodels: add v0.13.5 * Make dependency on "blt" of type "build"
44 lines
2.5 KiB
YAML
44 lines
2.5 KiB
YAML
# -------------------------------------------------------------------------
|
|
# This is the default spack configuration file.
|
|
#
|
|
# Settings here are versioned with Spack and are intended to provide
|
|
# sensible defaults out of the box. Spack maintainers should edit this
|
|
# file to keep it current.
|
|
#
|
|
# Users can override these settings by editing
|
|
# `$SPACK_ROOT/etc/spack/concretizer.yaml`, `~/.spack/concretizer.yaml`,
|
|
# or by adding a `concretizer:` section to an environment.
|
|
# -------------------------------------------------------------------------
|
|
concretizer:
|
|
# Whether to consider installed packages or packages from buildcaches when
|
|
# concretizing specs. If `true`, we'll try to use as many installs/binaries
|
|
# as possible, rather than building. If `false`, we'll always give you a fresh
|
|
# concretization. If `dependencies`, we'll only reuse dependencies but
|
|
# give you a fresh concretization for your root specs.
|
|
reuse: dependencies
|
|
# Options that tune which targets are considered for concretization. The
|
|
# concretization process is very sensitive to the number targets, and the time
|
|
# needed to reach a solution increases noticeably with the number of targets
|
|
# considered.
|
|
targets:
|
|
# Determine whether we want to target specific or generic
|
|
# microarchitectures. Valid values are: "microarchitectures" or "generic".
|
|
# An example of "microarchitectures" would be "skylake" or "bulldozer",
|
|
# while an example of "generic" would be "aarch64" or "x86_64_v4".
|
|
granularity: microarchitectures
|
|
# If "false" allow targets that are incompatible with the current host (for
|
|
# instance concretize with target "icelake" while running on "haswell").
|
|
# If "true" only allow targets that are compatible with the host.
|
|
host_compatible: true
|
|
# When "true" concretize root specs of environments together, so that each unique
|
|
# package in an environment corresponds to one concrete spec. This ensures
|
|
# environments can always be activated. When "false" perform concretization separately
|
|
# on each root spec, allowing different versions and variants of the same package in
|
|
# an environment.
|
|
unify: true
|
|
# Option to deal with possible duplicate nodes (i.e. different nodes from the same package) in the DAG.
|
|
duplicates:
|
|
# "none": allows a single node for any package in the DAG.
|
|
# "minimal": allows the duplication of 'build-tools' nodes only (e.g. py-setuptools, cmake etc.)
|
|
# "full" (experimental): allows separation of the entire build-tool stack (e.g. the entire "cmake" subDAG)
|
|
strategy: minimal
|