Re: NEW: geo/cdo

On Fri, 29 Aug 2025 15:08:36 +0200 Martin Reindl wrote:
> Am 2025-08-29 14:29, schrieb Marco van Hulten:
> > On Fri, 29 Aug 2025 07:54:30 +0200 Martin Reindl wrote:
> >> Am 2025-08-28 11:35, schrieb Marco van Hulten:
> >> > Hello,
> >> >
> >> > I ported CDO, a tool to manipulate and analyse climate and
> >> > numerical weather prediction (NWP) model data.
> >> >
> >> > https://code.mpimet.mpg.de/projects/cdo
> >> >
> >> > On amd64, 'make test' and 'make install' succeed. Reading netCDF and
> >> > GRIB1 files work. GRIB2 support is WIP (ecCodes needed for this), but
> >> > without it CDO is usable for most geoscientists in most cases.
> >> >
> >> > I posted a previous port version of the package on 21/23 June that
> >> > could
> >> > only read netCDF files. It had not been committed into CVS. This one
> >> > builds a newer version of CDO and includes GRIB1 support.
> >> >
> >> > Marco
> >>
> >> Hi Marco,
> >>
> >> This requires libaec-enabled HDF5 (and NetCDF), correct?
> >
> > Yes. I now added math/hdf5 to BUILD_DEPENDS, RUN_DEPENDS and
> > LIB_DEPENDS. Are the first two redundant when it is in LIB_DEPENDS?
>
> Yes, LIB_DEPENDS end up in BUILD and RUN_DEPENDS. See bsd.port.mk(5)
>
> But HDF5 and NetCDF need to be updated first to be able to read GRIB2
> files.
> This works for you because you likely built cdo with these updated
> ports.
>
> So people trying this port with GRIB2 files need to run these diffs too,
> just as a heads-up.

Yes, except you mean GRIB1 instead of GRIB2. libaec provides GRIB1
support to HDF5, which is in turn used by CDO. GRIB2 is only in
ecCodes (WIP), so I did not enable that yet in CDO.

Could you send again netcdf and hdf5? The former REVISION of netcdf was
increased because ngtcp2_crypto_quictls is replaced by
ngtcp2_crypto_libressl, so the patch must be changed.

I attached cdo again, but with redundant DEPENDS removed,
ngtcp2_crypto_libressl added and pkg/DESC reflecting it only supports
GRIB 1.

Marco