unnecessary calls to `find_dependency(ZLIB)` when depending on hdf5-shared

[minrk]

Describe the bug

find_dependency(ZLIB) is called in hdf5-config.cmake even though hdf5 links zlib internally, which means it is not relevant when linking to hdf5 as a shared library.

I believe the same issue applies to SZIP.

Expected behavior

I can link hdf5 as a shared library even when zlib development files are not available, as worked fine with 1.14.6. Specifically, find_dependency is only called on dependencies required to link hdf5.

Platform (please complete the following information)

• HDF5 version 2.1.0
• OS and version linux (alma9)
• Compiler and version: gcc 14
• Build system (e.g. CMake version) and generator (e.g. XCode, Ninja) CMake 4.3
• Any configure options you specified:

  cmake ${CMAKE_ARGS} -LAH -G "Ninja" \
   -DHDF5_ENABLE_ZLIB_SUPPORT=ON \
   -DHDF5_ENABLE_SZIP_SUPPORT=ON \
   -DHDF5_BUILD_CPP_LIB=ON \
   -DHDF5_BUILD_HL_LIB=ON \
   -DHDF5_BUILD_FORTRAN=ON \
   -DHDF5_BUILD_EXAMPLES=OFF \
   -DHDF5_H5CC_C_COMPILER=`basename ${CC}` \
   -DHDF5_H5CC_CXX_COMPILER=`basename ${CXX}` \
   -DHDF5_H5CC_Fortran_COMPILER=`basename ${FC}` \
   -DH5_DEFAULT_PLUGINDIR="${PREFIX}/lib/hdf5/plugin" \
   -DHDF5_ENABLE_THREADSAFE=ON \
   -DHDF5_ALLOW_UNSUPPORTED=ON \
   -DHDF5_ENABLE_ROS3_VFD=ON \
   -DHDF5_ENABLE_NONSTANDARD_FEATURES=OFF \
   -DBUILD_STATIC_LIBS=OFF \
   -B build .
  

• MPI library and version (parallel HDF5) none

Additional context

This is coming up on conda-forge, where the zlib development package (containing headers, cmake files, etc.) is a new requirement to build against hdf5, where it wasn't before, only needing the actual runtime library. zlib is not linked at any point in this process, so this produces an incorrect direct dependency on zlib for packages that only link hdf5.

Related issues:

• similar discussion in Problems with ZLIB::ZLIB missing from INTERFACE_LINK_LIBRARIES in installed release target hdf5-shared #6279
• these calls were added in Using system compress libs add dependency to the install #5547 to address find_package(ZLIB) for compatibility with more recent hdf5 CGNS/CGNS#834 which I think is specific to hdf5-static, and not applicable to a shared library build

Suggested solution

Add an appropriate conditional here so that find_dependency is only called on transitive dependencies when they are needed to link to hdf5, which I think would only be static builds. It's possible that this is just adding AND @BUILD_STATIC_LIBS@, but it may be more complex than that.

[minrk]

I suppose the right condition would be whether static is one of the searched-for components, not just if static libraries exist.

[jhendersonHDF]

Hi @minrk,

I believe that logic was added to try to solve the related zlib/libaec issues in CGNS, but I also believe that you're right in that it didn't account for shared vs. static. We'd need to check whether static libraries are the only ones provided or if both are provided and static are in the list of components being looked for, or if no components are specified. When components aren't specified, it looks like we're currently providing static libraries by default, if available.

[minrk]

I think you're right. conda-forge/hdf5-feedstock#302 tests the simplest patch to add AND ${HDF5_PACKAGE_NAME}_PROVIDES_STATIC_LIBS which adds the test only if static libs are available (they aren't on conda-forge). It's still an unnecessary check if the static libs are present but not requested, but:

1. I think it's needed before loading the static targets, which currently get loaded before checking components, so would require a larger refactor to shift loading the targets later after checking the component list
2. it's relatively rare outside conda-forge-style empty build environment situations for zlib headers to be unavailable, so it's a low-impact issue

so if someone more comfortable with a refactor like that wants to make it, that would solve it, I think. Otherwise, my small patch works for the simple shared-only case, improving the situation for us, if not fixing it for all cases.

[jhendersonHDF]

Thanks, I'll take a look at this. I think it only makes sense to check the components before loading the targets files anyway and I've seen many other CMake projects that handle it in this manner.