xsdk: add +sycl variant - with amrex, arborx, ginkgo, petsc, sundials
xsdk: add +pflotran variant
xsdk: enable hypre+rocm
xsdk: enable superlu-dist for GPU - but use trilinos~superlu-dist [as that breaks builds]
xsdk: dealii: disable oce as it can cause intel-tbb-2017.6 to be picked up for some builds (for ex: gcc=13) and result in subsequent build failures
Some environments may have `dd4hep` as a concretized package without having it installed (yet). For those environments, `dd4hep` has property `libs` that is an empty list. Nevertheless, it can be added to a run environment (for example in case `dd4hep` is part of an environment). This results in an IndexError:
```
==> Warning: couldn't load runtime environment due to IndexError: list index out of range
```
To avoid the IndexError, only prepend the `dd4hep` libs if there are actually libs found.
Tests didn't cover the new `--variants-by-name` parameter in #40998.
Add some parameterization to hit that.
This changeset makes me think that the main section-printing loop in `spack info` isn't
factored so well. It makes it difficult to pass different arguments to different helper
functions. I could break it out into if statements if folks think that would be cleaner.
* dealii: 9.5.0
* kokkos+cuda_lambda
* dealii ^kokkos@3.7: require +cuda +cuda_lambda +wrapper
* Added 9.5.1, try ~cgal when +cuda
* Forward Cuda architecture request
* Remove workaround
* Try not enforcing the Kokkos compiler
* Enforce using nvcc_wrapper with Trilinos+Cuda
* Don't define CMAKE_*_COMPILER to point to MPI wrappers
* Use the same compiler as Trilinos/Kokkos
* Only check for Trilinos compiler
* Disable Trilinos+Cuda
* Disable Cuda support
* Try CUDA build without ninja
* Combined examples and examples_compile
* Use f-string for cuda_arch
* p -> _package
* Indentation
* Fix up f-string
---------
Co-authored-by: Luca Heltai <luca.heltai@sissa.it>
Co-authored-by: eugeneswalker <eugenesunsetwalker@gmail.com>
We have two ways to concretize now:
* `spack concretize` concretizes only the root specs that are not concrete in the environment.
* `spack concretize -f` eliminates all cached concretization data and reconcretizes the *entire* environment.
This PR adds `spack deconcretize`, which eliminates cached concretization data for a spec. This allows
users greater control over what is preserved from their `spack.lock` file and what is reused when not
using `spack concretize -f`. If you want to update a spec installed in your environment, you can call
`spack deconcretize` on it, and that spec and any relevant dependents will be removed from the lock file.
`spack concretize` has two options:
* `--root`: limits deconcretized specs to *specific* roots in the environment. You can use this to
deconcretize exactly one root in a `unify: false` environment. i.e., if `foo` root is a dependent
of `bar`, both roots, `spack deconcretize bar` will *not* deconcretize `foo`.
* `--all`: deconcretize *all* specs that match the input spec. By default `spack deconcretize`
will complain about multiple matches, like `spack uninstall`.
