1.14.0 and remove static builds

[hmaarrfk]

I really don't think we should be dragging along the static builds. The build process isn't really nice toward building both the static and the dynamic library. I think we are going to be better off without this for 1.14.0

Let me know what you all think

• Check if I have to include static builds again Getting rid of the -static builds #185
• Discuss skipping the ROS3 test on windows -- [BUG] Windows ROS3 broken in 1.14.0? HDFGroup/hdf5#2406
• Atomicity tests known to fail: Atomicity Test Failed Process 1: read_buf[2047] is 0, should be 5 HDFGroup/hdf5#2196
• Remove huge patch to rename executable files in cmake in favor of renaming them in the build script

Upstream changes

• Upstream changed from -show to -showconfig for cmake generated h5cc https://github.com/HDFGroup/hdf5/blob/e4fb9aa96ef805e2dada8a78c32aab8cf8c34f4a/release_docs/HISTORY-1_13.txt#L1111
• Patched out the use of the statically linked binaries for windows making the comrpessed package 3x smaller

TODO:

• Create a branch for 1.12.X maintenance (this will be necessary since HDF5 is typically a hard transition)

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[hmaarrfk]

The really heavy handed patching is to remove all the statically linked binaries from windows:

[hmaarrfk]

The executables that link to the shared libraries take 10s of kB, those that statically link take MBs

[hmaarrfk]

@djhoese i'm not sure if you are still interested in ROS3 functionality on windows.

[djhoese]

It isn't clear to me what ROS3 has to do with this PR or static builds. ROS3 should be made to work on all platforms if upstream supports it. If the tests fail on Windows due to some CI limitation then OK.

[hmaarrfk]

@conda-forge-admin please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/hdf5-feedstock/actions/runs/3924159046.

[mkitti]

Do we need to synchronize this with a h5py update?

h5py 3.8.0 was released a few hours ago, including support for HDF5 1.14
https://github.com/h5py/h5py/releases/tag/3.8.0

[mkitti]

h5py was updated to 3.8.0:
conda-forge/h5py-feedstock#125

This incorporates the patches needed for 1.14 support.

[hmaarrfk]

Do we need to synchronize this with a h5py update?

In essence, not really. h5py is pinned to the previous version of HDF5 through the run_export.

So this could be merged, without any fear of breaking existing user's H5PY installation.

Im mostly leaving this here for people to comment on the removal of the static builds. But to me, it seems that they were added as an abundance of caution.

[mkitti]

It would be nice if the shared versions were aliased to the static versions in this case via a symlink or just copying so that typing h5ls would still work.

[hmaarrfk]

h5ls-dynamic seems to be a creation of the cmake files.

doesn't h5ls still work? The tests say they do.

I aggressively patched windows to make h5ls exist (even when building dynamic only) but to remove h5ls-dynamic. I'm honestly not proud of the aggressive patching. Maybe we should just "rename" the executable instead of patching so much. I'm happy to report this as an issue upstream as well.

Edit: clarification. I am not proud of the aggressive patching.

[mkitti]

Ah, I see. It might be worth discussing at https://forum.hdfgroup.org/ first?

[mkitti]

It might make sense to split the tools off to another package. Some Linux distributions do this:
https://packages.debian.org/bullseye/hdf5-tools
https://pkgs.org/search/?q=hdf5-tools

[hmaarrfk]

discussing at https://forum.hdfgroup.org/ first?

Presently, I am too tired to articulate to a wider audience, but maybe over the weekend i can formulate my thoughts?

I am tempted to reimplement this as a "file rename" in our build script instead of a huge patch.

[hmaarrfk]

It might make sense to split the tools off to another package

Two aspects:

1. conda doesn't really make this "easy". For example, with RPMs I can specify a list of files I want in a subpackage, then everything else goes in the main package. This ensures I don't "miss" anything in the subpackage creation. This process in conda (to my knowledgE) is a little manual, and error prone.
2. conda has historically been more "batteries included" (including more options than "the bare minimum") than other distributions. The binaries executables on linux only take up 2MB / 11.1MB as reported by ncdu. Unless somebody wants to step up and "help maintain", I'm not so inclined to split the package given 1.. As a note, uncompressed, the headers make up 2.8/11.1 MB.

[hmaarrfk]

@conda-forge-admin please restart cis

[hmaarrfk]

@conda-forge/hdf5 this is ready for review.

I'm hoping to merge Feb 5.

[hmaarrfk]

Thank you all for your reviews.

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!