netCDFTargets.cmake and pkgconfig netcdf.pc have wrong hdf5 libraries

[Chrismarsh]

If netcdf-c is built as a shared library with cmake, the installed netCDFTargets.cmake and pkconfig netcdf.pc list hdf5_hl-shared and hdf5-shared as dependent libraries. These libraries do not exist and are (seemingly) the names of the hdf5 target: hdf5::hdf5-shared.
E.g.,

Libs.private: -lhdf5_hl-shared -lhdf5-shared -lm -lz -lzstd -lbz2 -lcurl -lpnetcdf -lxml2

This ends up being problematic as consumer libraries (vtk9 in my case) tries to use these libraries and fails to find them.

I see in my test that

find_package(HDF5 COMPONENTS C HL REQUIRED)

message(STATUS "${HDF5_LIBRARIES}")
message(STATUS "${HDF5_C_LIBRARIES}")

Produces:
hdf5-shared as output. Given that is how it is used here
https://github.com/Unidata/netcdf-c/blob/v4.9.2/liblib/CMakeLists.txt#L119
it's not surprising this shows up as an issue.

I see references to this problem here
https://bugs.gentoo.org/833943
and
#1444 (comment)

Ammending the filter here
https://github.com/Unidata/netcdf-c/blob/main/CMakeLists.txt#L1595
fixes the pkgconfig, and I think a similar here
https://github.com/Unidata/netcdf-c/blob/v4.9.2/liblib/CMakeLists.txt#L121
would filter it out for the cmake (testing now).

I'm wondering if there was other progress on this issue or if I should submit this as a fix as a PR?

[WardF]

I'm taking a closer look at this, a PR would be a great, I'm failing to replicate this issue but it clearly exists, so I'm trying to narrow down the circumstances in which it occurs.