Drafting due to legitimate build failures.

The PR is ready @BillyONeal.

The PR is ready, but I'm not sure why the x64_android triplet failed. We don't support Android for this port, so it's likely a CI-related issue.

Hm, I start wondering if ecbuild should be a port or just another download in eccodes.
All wrappers on top of CMake add their own problems. (Vcpkg included...)

Hm, I start wondering if ecbuild should be a port or just another download in eccodes. All wrappers on top of CMake add their own problems. (Vcpkg included...)

I considered both options. I kept ecbuild as a helper port because it is a CMake macro/build-system package, and using a host helper port makes the dependency explicit, avoids relying on ecCodes' FetchContent path, and keeps the ecCodes port focused on building ecCodes itself.

That said, if the preference is to avoid introducing a separate helper port for ecbuild, I can fold the ecbuild download into the eccodes port and pass the local ecbuild source path directly during configure.

Everything is OK now @BillyONeal. Check again.

ecbuild is a CMake macro/helper package, and its macros expect the full upstream cmake module directory to be available through CMAKE_MODULE_PATH. ecCodes uses ecbuild's package-discovery layer, including NetCDF detection, so removing the Find modules makes this helper port incomplete.

Sometimes these 3rd-party Find modules are not helpers but evil. They cannot know (but only guess) how we configured the dependency. We have CMake config and we have wrappers for official (Kitware) Find modules to capture the configuration when we build the dependency. You have to patch anyways, so you might as well patch for adopting the known-good package provider.

netcdf-c provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(netCDF CONFIG REQUIRED)
  target_link_libraries(main PRIVATE netCDF::netcdf)

ecbuild is a CMake macro/helper package, and its macros expect the full upstream cmake module directory to be available through CMAKE_MODULE_PATH. ecCodes uses ecbuild's package-discovery layer, including NetCDF detection, so removing the Find modules makes this helper port incomplete.

Sometimes these 3rd-party Find modules are not helpers but evil. They cannot know (but only guess) how we configured the dependency. We have CMake config and we have wrappers for official (Kitware) Find modules to capture the configuration when we build the dependency. You have to patch anyways, so you might as well patch for adopting the known-good package provider.

netcdf-c provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(netCDF CONFIG REQUIRED)
  target_link_libraries(main PRIVATE netCDF::netcdf)

Done. I patched ecCodes to use the vcpkg-provided netcdf-c config package directly instead of relying on ecbuild's FindNetCDF.cmake.

The netcdf feature now uses find_package(netCDF CONFIG REQUIRED) and links grib_to_netcdf with netCDF::netcdf. I also excluded ecbuild's upstream Find*.cmake files again, so the helper port no longer installs those third-party Find modules.

With this, netcdf discovery comes from the known vcpkg package provider instead of ecbuild's heuristic module.

@vicroms points out that since CMAKE_MODULE_PATH was not being obviously changed it's possible the installed find modules were being ignored.

@vicroms points out that since CMAKE_MODULE_PATH was not being obviously changed it's possible the installed find modules were being ignored.

Good point. The earlier failure does not necessarily prove that the installed ecbuild Find*.cmake modules were being used.

The helper config does add ecbuild's cmake directory to CMAKE_MODULE_PATH so that ecbuild's own macros can be included, but after the latest change this no longer matters for NetCDF: the ecCodes patch now uses find_package(netCDF CONFIG REQUIRED) and links netCDF::netcdf directly.

So the final state is still to exclude ecbuild's third-party Find*.cmake modules and use the vcpkg-provided config package for NetCDF.