diff options
| author | Seth R. Johnson <johnsonsr@ornl.gov> | 2022-03-08 13:15:10 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-03-08 13:15:10 -0500 |
| commit | 5bea24526f4ee27d94f5ce9d61d63babbc05bc38 (patch) | |
| tree | d223ff6a613f4aeaefaf8891d7b7e5c6d4ad99fa /var/spack/repos/builtin/packages/hdf5 | |
| parent | 57b27023a4ef25b9a3303eb5f372c051d994a934 (diff) | |
| download | spack-5bea24526f4ee27d94f5ce9d61d63babbc05bc38.tar.gz spack-5bea24526f4ee27d94f5ce9d61d63babbc05bc38.tar.bz2 spack-5bea24526f4ee27d94f5ce9d61d63babbc05bc38.tar.xz spack-5bea24526f4ee27d94f5ce9d61d63babbc05bc38.zip | |
Fix overconstrained HDF5 variants (#29132)
* hdf5: mark +fortran+shared conflict for older version
This version was only activated unintentionally by silo's conflict
statement, but `@1.8.15+shared+fortran+cxx` errors out in configure:
```
CMake Error at CMakeLists.txt:814 (message):
**** Shared FORTRAN libraries are unsupported ****
```
* silo: refine hdf5 conflicts to avoid building old version
Before this, `silo+hdf5` concretized to 1.10.7 or sometimes 1.8.15. Now
I've verified it works for the following configurations:
```
silo@4.10.2 patches=7b5a1dc,952d3c9
^ hdf5@1.10.7 api=default
silo@4.10.2 patches=7b5a1dc,952d3c9,eb2a3a0
^ hdf5@1.10.8 api=v18
silo@4.10.2 patches=7b5a1dc,952d3c9,eb2a3a0
^ hdf5@1.12.1 api=v110
silo@4.11-bsd patches=eb2a3a0
^ hdf5@1.12.1 api=v110
silo@4.11-bsd patches=eb2a3a0
^ hdf5@1.10.8 api=default
silo@4.11-bsd patches=eb2a3a0
^ hdf5@1.12.1 api=default
```
and verified that the following fail:
```
silo@4.10.2 ^hdf5@1.12.1 api=default
silo@4.11 ^hdf5 api=v18
silo@4.11-bsd ^hdf5@1.13.0 api=v12
silo@4.11-bsd ^hdf5@1.13.0 api=default
```
and have updated the constraints to match. Hdf5 no longer has to be
downgraded to work with Silo.
* silo: fix dependency conflicts
* py-h5py: shorten and add comments to py-h5py hdf5 dependencies
* e4s: remove slightly outdated hdf5 requirement
* e4s: remove excessive hdf5 variant constraints
These I think are holdovers from the old concretizer.
- `hdf5_compat` can be expressed as `+hdf5 ^hdf5@1.8`
- The extra variants on hdf5 shouldn't break conduit
- axom unnecessarily restricts hdf5 version
* conduit: restore hdf5_compat flag
Diffstat (limited to 'var/spack/repos/builtin/packages/hdf5')
| -rw-r--r-- | var/spack/repos/builtin/packages/hdf5/package.py | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/var/spack/repos/builtin/packages/hdf5/package.py b/var/spack/repos/builtin/packages/hdf5/package.py index c177fbc3da..409e427345 100644 --- a/var/spack/repos/builtin/packages/hdf5/package.py +++ b/var/spack/repos/builtin/packages/hdf5/package.py @@ -108,6 +108,8 @@ class Hdf5(CMakePackage): conflicts('+java', when='@:1.9') # The Java wrappers cannot be built without shared libs. conflicts('+java', when='~shared') + # Fortran cannot be built with shared + conflicts('+fortran', when='+shared@:1.8') # There are several officially unsupported combinations of the features: # 1. Thread safety is not guaranteed via high-level C-API but in some cases |