54210270c8
Currently, when we setup the ASP problem for `clingo`, we don't take into account the configuration. This results in setting up ASP problems that are larger than necessary, with possibly redundant information, and higher concretization times. This PR tries to improve things by adding an opt-in feature that computes the _possible dependencies_ of a solve taking also into account the current configuration, and avoids adding possible dependencies that we are certain can't be in the final solution. The feature can be activated with: ```yaml concretizer: static_analysis: true ``` Examples of simple rules to discard dependencies are: - Dependencies that are not buildable, and for which no binary is present (e.g. `cray-mpich` etc. on non Cray systems) - Dependencies that are not for the current platform (e.g. `msmpi` on non Windows platforms) - Conditional dependencies that cannot be activated, because of some user requirement (e.g. `cuda` etc. if the user requires `~cuda` in configuration) - Virtual providers that cannot be used, because of a requirement on a virtual The speed-up these rules seem to give depends on the use case at hand, but if the configuration is updated properly, they are noticeable. Since in cases where there is no rule to exclude packages upfront, reuse is active, and this option is activated, it's possible to see some minor slow down, the feature has been added as opt-in, so it's turned off by default.
70 lines
3.9 KiB
YAML
70 lines
3.9 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
|
|
# 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
|