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

• cdo-2.5.3.tar.gz (2K)