cray-mpich now has a rocm variant. You can use gtl_lib in the
flag_handler like so:
```python
def flag_handler(self, name, flags):
wrapper_flags = []
environment_flags = []
build_system_flags = []
if self.spec.satisfies("+rocm"):
if self.spec.satisfies("^cray-mpich"):
gtl_lib = self.spec["cray-mpich"].package.gtl_lib
build_system_flags.extend(gtl_lib.get(name) or [])
# hipcc is not wrapped, we need to pass the flags via the
# build system.
build_system_flags.extend(flags)
return (wrapper_flags, environment_flags, build_system_flags)
```
---------
Co-authored-by: Richard Berger <rberger@lanl.gov>
Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Co-authored-by: Richard Berger <richard.berger@outlook.com>
* postgresql: add version 17.2
* postgresql: install flex, bison and perl when building versions 17 and up
* postgresql: do not install perl by default when building versions 17 and up
This PR is effectively a breaking change extracted from #45189, which removes
support for spec["mpi"] if spec itself is openmpi / mpich that could provide mpi;
from the Spec instance we don't have any parent it provides it to,
hence it's a KeyError.
* g4vg: add develop version
* celeritas: add develop version
* Fix style
* REVERTME: move celeritas changes to another branch
* Get full repo
* remove unneeded variable
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>
