Currently, a few packages using kokkos rely on
kokkos itself monkeypatching its own spec to
provide some attribute.
In this commit we change this attribute to be
defined on the package, and never be monkeypatched.
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.
* Bump up the version for rocm-6.3.2 release
* rocm-openmp-extras update and style correction
* Updating mivisionx, omniperf, rccl & rocprofiler-systems
* Updating hipsparselt & rocm-opencl
* rocprofiler-systems on gcc-13 and rvs commit instead of patch
* Updated rocjpeg & rocm-examples for 6.3.2
* ROCPROFSYS_BUILD_DYNINST & DYNINST_BUILD_TBB are required only with gcc-13
---------
Co-authored-by: afzpatel <122491982+afzpatel@users.noreply.github.com>
Current location is within the Spack prefix, which causes builds to
pollute VCS with stage artifacts and generally inflates the Spack
install prefix.
This PR moves it to the user cache location now that we can
consistently support paths with spaces on Windows.