From: Landry Breuil <landry@openbsd.org>
Subject: Re: NEW: geo/cdo
To: Marco van Hulten <marco@hulten.org>
Cc: ports@openbsd.org
Date: Thu, 4 Sep 2025 12:47:40 +0200

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..

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 ?

if so, that means it cant be imported until the aec support in hdf5 is
enabled (which isnt a big deal)

Landry