Workaround broken cmake config file

[jschueller]

try to work around Unidata/netcdf-c#1444
we manually pass hdf5 variables to avoid the find_package path which results in target names being added to cmake target config files instead of actual library paths.

[conda-forge-linter]

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.

[kmuehlbauer]

@jschueller @xylar Sorry for being late to the party. Not sure if this helps, but it seems the issue will be solved netcdf-c, see Unidata/netcdf-c@023d3e9.

Asking @WardF if this will fix the issue?

[jschueller]

yes, dont merge anything yet, i'll try to backport in another pr

[xylar]

@jschueller, it might be worth adding yourself as a maintainer.

[WardF]

@jschueller @xylar Sorry for being late to the party. Not sure if this helps, but it seems the issue will be solved netcdf-c, see Unidata/netcdf-c@023d3e9.

Asking @WardF if this will fix the issue?

That branch will fix it, but not as it currently stands. HDF5 logic is tricky, and I need to port over some additional work from the netcdf-c/CMakeLists.txt file :).

[kmuehlbauer]

@jschueller @xylar Sorry for being late to the party. Not sure if this helps, but it seems the issue will be solved netcdf-c, see Unidata/netcdf-c@023d3e9.
Asking @WardF if this will fix the issue?

That branch will fix it, but not as it currently stands. HDF5 logic is tricky, and I need to port over some additional work from the netcdf-c/CMakeLists.txt file :).

@WardF Thanks for the update, much appreciated!

[jschueller]

I propose to merge this PR untils the fix lands in a netcdf to let wardf time to investigate.

[xylar]

I'm going to give folks the rest of today to comment one way or the other and then I'll merge.