hdf5: use CMake

[jpfeuffer]

closes #157329 (supersedes it)
closes #157078

tagging @SMillerDev

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[github-actions]

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[jpfeuffer]

I'm not an expert but the dep failures seem unrelated.

[ZhongRuoyu]

Yes, failures seem unrelated; see also: https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+shmget

[Porkepix]

Does it really need linux self-hosted runners? Slightly more than 1H15 on it seems pretty short and could probably fit within 6H of GitHub runners, right?

[ZhongRuoyu]

Does it really need linux self-hosted runners? Slightly more than 1H15 on it seems pretty short and could probably fit within 6H of GitHub runners, right?

I think it did time out while testing dependents in #140211.

[Porkepix]

Mmmmh, maybe also because there were two formulas there vs. only one here.

[jpfeuffer]

Speaking of which: we could add the changes for the hdf5-mpi formula as well. Could benefit from the Cmake- and pkg-config files for easier discoverability as well.
I didn't know about that formula and I'm personally not using it, so I'm not sure if it needs special treatment.

[SMillerDev]

Let's merge this, and then please make a new PR for hdf5-mpi @jpfeuffer

[github-actions]

@ZhongRuoyu has requested bottles to be published to this PR.

[eli-schwartz]

This is causing universal CI failures for attempting to detect and compile against hdf5 in the Meson CI.

hdf5 cannot and must not ever be built with cmake. Using broken build files that upstream doesn't seriously support, just to make cmake's find_package() detect hdf5, is not a real solution. There's a reason that every linux distro I'm aware of builds hdf5 with autotools -- sometimes with comments about how the cmake support is utterly broken, sometimes without comment.

[jpfeuffer]

EDIT: Ignore. I thought you were saying the config files are broken.

Can't you just search in "MODULE" mode then? No one forces someone to use those config files.
And how about raising the problems at the HDF5 repository (potentially repeatedly) until they are fixed. IMHO ignoring the problem is also not a solution.
The config files work great for us and without config files you will never have easy access to compile flags and some more modern CMake features that depend on more detailed descriptions of the targets.

[jpfeuffer]

Ok it looks like you're saying the build itself is broken with CMake. That is hard for me to judge and I would be interested in some of the bug reports of the distros.
Your specific linked case "just" seems to have problems with the c++ standard version and a (probably) missing -lhdf5 in your linker command line.
But I think most importantly this should be posted on a HDF5 issue tracker. Ignoring it won't make it go away.
There is already a forum thread with some of the maintainers on HDF5 where people are discussing dropping maintenance of Autotools scripts.
https://forum.hdfgroup.org/t/can-we-retire-the-autotools/10362/31

[blawrence-ont]

It appears that this change has broken cmake's FindHDF5 module: https://github.com/Kitware/CMake/blob/master/Modules/FindHDF5.cmake

The module works by calling h5cc with -show to extract the libraries it needs to link to. Previous versions of h5cc handle -show correctly:

% h5cc -show 
clang -I/opt/homebrew/opt/libaec/include -L/opt/homebrew/Cellar/hdf5/1.14.3/lib /opt/homebrew/Cellar/hdf5/1.14.3/lib/libhdf5_hl.a /opt/homebrew/Cellar/hdf5/1.14.3/lib/libhdf5.a -L/opt/homebrew/opt/libaec/lib -lsz -lz -ldl -lm

However with these changes h5cc now returns:

% h5cc -show 
/opt/homebrew/h5cc
dir is /opt/homebrew
clang: error: unknown argument: '-show'

This appears to be because the script is now a very thin wrapper missing a lot of functionality: compare the arg handling in the version that used to be provided https://github.com/HDFGroup/hdf5/blob/develop/bin/h5cc.in with the version now provided https://github.com/HDFGroup/hdf5/blob/develop/config/cmake/libh5cc.in.

Also it surprises me that this change has more than tripled the size of the package from 21.4MB to 77.7MB according to brew info hdf5.

[jpfeuffer]

Ok sorry, let's revert. Unfortunately I do not have the resources to debug this.
The idea was actually not to rely on the hand-written, externally updated FindHDF5 module that also lacks information about compiler options, runtime dependencies and shared vs static targets distinction.
But I think this is out of reach.

[jpfeuffer]

I will forward this to the HDF forum though.

[eli-schwartz]

Can't you just search in "MODULE" mode then? No one forces someone to use those config files.

Sure.

Just tell me how to do that from an autotools Makefile and I will get right on that immediately.

Considering that hdf5 has been pretty apathetic about delivering pkg-config files even after delivering them for cmake, there's lots of code out in the wild that uses h5cc -show.

Your specific linked case "just" seems to have problems with the c++ standard version and a (probably) missing -lhdf5 in your linker command line.

And at minimum, the missing -lhdf5 is because of the well known problem that cmake's version of h5cc heard about the idea of "compatibility" and said "what's that, some kind of boring Linux thing?" and implemented the absolute minimum scaffolding needed to be invoked internally by their cmake config file, and absolutely nothing for existing users.

If for no other reason, distributors have to ship an autotools build because they need to support existing software that relies on h5cc working. That software cannot use pkg-config because distributors ship an autotools build. This recursive logic will be fixed exactly no sooner than whenever upstream hdf5 accepts that the request to ship a pkg-config file for autotools isn't a request that should be ignored and closed every time someone offers one, then left to rot forever.

Admittedly it was some time ago that I was aware of the general brokenness of the cmake build. It is possible that at the time the cmake build was still windows-only despite advertising itself for Linux use, but I don't remember. Maybe it's gotten better. Given the overall disaster that is hdf5 and build systems, I'm not hopeful. They responded to the issue of h5cc being broken with "we have documented in the release.txt that h5cc has changed. Closing this bug report as solved".

[eli-schwartz]

Also it surprises me that this change has more than tripled the size of the package from 21.4MB to 77.7MB according to brew info hdf5.

This is because, even for a project notable for lacking expertise at build systems, they have orders of magnitude less expertise in cmake than they have in autotools.

But some of it is just cmake's fault, because CMake Is That Way™.