-
-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recent HDF5 package in conda-forge (1.14.4) does not define HDF5_VERSION in CMake #5164
Comments
Version 1.14.4 has trouble: HDFGroup/hdf5#5164
I have inspected the CMake code and the config files produced and cannot find anything that would affect the VERSION string. |
* Conda: Pin HDF5 to 1.14.0 in CI workflow Version 1.14.4 has trouble: HDFGroup/hdf5#5164 * Try 1.14.1
I think that this might rather be an issue in the Conda packaging and not in the HDF5 CMake scripts themselves, considering that I do not have these problems with a self-compiled installation of HDF5.
Find below the FindHDF5.cmake file (had to add the .txt ending for GitHub). I also noticed that in the Conda environment, both in the failing CI run and in my local reproducer, there is a line The CMake variables for HDF5 in the Conda environment look as follows:
For my self-compiled version, they are:
For what it's worth, here are the hdf5-config-*.cmake files for the self-installed version, but those work correctly anyway cmake.zip |
Is it because we are using the configure script instead of the cmake build system? We could switch from one build system to the next in the next release of HDF5. Either 1.14.5 (since we haven't released yet), or 1.14.6. Unfortunately we can't do it for releases that we have already made. |
find_package falls back to module mode (FindHDF5.cmake in the CMake repo) when it encounters an autotools build. So the missing HDF5_VERSION is a result of that CMake Find module. |
this makes our decision REALLY easy in 2.0.0 ^_^
I think I'm just misunderstanding your wording since i'm not an expert at cmake configuration and fallbacks thereof. Given the fact that conda-forge uses autotools (for now 1.14.3 and 1.14.4 being our latest released versions), is there anything we can do to help cmake users beyond moving to a cmake build system? We could do this as part of our 1.14.5 update. |
I don't know why the HDF5_VERSION value is not being set, it must be some failure/issue in the CMake FindHDF5.cmake module file? Maybe it has an issue with asking for 1.14.0 and only having 1.14.4? A test would be to ask for 1.14.4 and see if the HDF5_VERSION is set? |
So this is not a bug, but just how that installation works? To be fair, I did not look into the CMake logic of HDF5, just tried to narrow down the conditions under which this behavior occurs.
I can try that out, but I think that it won't make a difference; where I first saw this issue, the |
Yep, no difference:
|
Describe the bug
CMake scripts that include HDF5 can normally use
HDF5_VERSION
to determine the version of the found HDF5 installation. For some reason, the current package available on conda-forge does not set this variable.To reproduce, use a minimal CMakeLists.txt:
Create a test environment with Conda (I'm using miniforge3 on LinuxMint 21.3, but saw this originally in a CI run with conda-forge on Ubuntu 22.04):
. miniforge3/bin/activate conda create -n hdf5-debug conda activate hdf5-debug conda install hdf5 cmake compilers pkg-config
This currently installs HDF5 1.14.4.
Then try configuring the above CMake script and see that the variable is apparently not set (ref. the line saying
-- HDF5 version:
:Downgrading to HDF5 1.14.0 will fix this:
The issue does not occur with a self-compiled version of HDF5 1.14.4:
Expected behavior
HDF5_VERSION
should be defined.Platform (please complete the following information)
Additional context
Failing CI run: https://github.com/openPMD/openPMD-api/actions/runs/12012158126/job/33600997878
The text was updated successfully, but these errors were encountered: