From: Marco van Hulten Subject: Re: NEW: geo/cdo To: Landry Breuil Cc: ports@openbsd.org Date: Thu, 4 Sep 2025 15:19:28 +0200 On Thu, 4 Sep 2025 12:47:40 +0200 Landry Breuil wrote: > Le Thu, Sep 04, 2025 at 12:03:44PM +0200, Marco van Hulten a écrit : > > On Mon, 1 Sep 2025 14:39:04 +0200 Marco van Hulten wrote: > > > 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. > > > > Now there is also GRIB 2 support. (And changed back pkg/DESCR to > > reflect this.) Needs just submitted geo/eccodes port. > > from a quick look from a ports 'standards' perspective: > > LIB_DEPENDS should be one entry by line, eg > LIB_DEPENDS = math/netcdf \ > math/hdf5 \ > math/udunits \ > geo/eccodes > > same thing for CONFIGURE_ARGS > > no need to 'format' WANTLIB, usually you just copypaste 'make > port-lib-depends-check' output. > > for CONFIGURE_ENV if you hardcode CC/CXX to clang then there's no point > in adding 'ports-gcc' to COMPILER, that should be base-clang > ports-clang. > > and if the build requires egfortran, then there should be a > BUILD_DEPENDS on a working gcc version, whatever the default is.. Also taking Stuart's comments into account, attached is a new version. Base clang appears to be enough. > I'll try building it when i've looked at eccodes. > > my understanding (after quickly skimming through the various mails about > the topic) is that this also requires hdf5 built with aec support, is > that right ? My port depends on hdf5 and aec, but I am not certain if hdf5 with aec is necessary. Maybe now with eccodes (which also depends on and supports GRIB1 and GRIB2, among other formats), it is not needed. But I have not tested that. > if so, that means it cant be imported until the aec support in hdf5 is > enabled (which isnt a big deal) I think it's best keep the cdo port as is (concerning hdf5 and aec), so yes after this import. Marco