3caa3132aa
Python was removed from being a build tool in #46980, due to issues when reusing specs. This PR adds a new rule to match the interpreter among different Python packages, in clingo. It also adds a bunch of new "build-tools", so that specs like: ``` py-matplotlib backend=tkagg ``` can be concretized in one go. Modifications: - [x] Make `py-matplotlib backend=tkagg` concretizable - [x] Add unit-tests to ensure situations like in #46980 do not happen --------- Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
92 lines
4.4 KiB
YAML
92 lines
4.4 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: true
|
|
# 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
|
|
# Maximum number of duplicates in a DAG, when using a strategy that allows duplicates. "default" is the
|
|
# number used if there isn't a more specific alternative
|
|
max_dupes:
|
|
default: 1
|
|
# Virtuals
|
|
c: 2
|
|
cxx: 2
|
|
fortran: 1
|
|
# Regular packages
|
|
cmake: 2
|
|
gmake: 2
|
|
python: 2
|
|
python-venv: 2
|
|
py-cython: 2
|
|
py-flit-core: 2
|
|
py-pip: 2
|
|
py-setuptools: 2
|
|
py-wheel: 2
|
|
xcb-proto: 2
|
|
# Compilers
|
|
gcc: 2
|
|
llvm: 2
|
|
# Option to specify compatibility between operating systems for reuse of compilers and packages
|
|
# Specified as a key: [list] where the key is the os that is being targeted, and the list contains the OS's
|
|
# it can reuse. Note this is a directional compatibility so mutual compatibility between two OS's
|
|
# requires two entries i.e. os_compatible: {sonoma: [monterey], monterey: [sonoma]}
|
|
os_compatible: {}
|
|
|
|
# Option to specify whether to support splicing. Splicing allows for
|
|
# the relinking of concrete package dependencies in order to better
|
|
# reuse already built packages with ABI compatible dependencies
|
|
splice:
|
|
explicit: []
|
|
automatic: false
|
|
# Maximum time, in seconds, allowed for the 'solve' phase. If set to 0, there is no time limit.
|
|
timeout: 0
|
|
# If set to true, exceeding the timeout will always result in a concretization error. If false,
|
|
# the best (suboptimal) model computed before the timeout is used.
|
|
#
|
|
# Setting this to false yields unreproducible results, so we advise to use that value only
|
|
# for debugging purposes (e.g. check which constraints can help Spack concretize faster).
|
|
error_on_timeout: true
|
|
|
|
# Static analysis may reduce the concretization time by generating smaller ASP problems, in
|
|
# cases where there are requirements that prevent part of the search space to be explored.
|
|
static_analysis: false
|