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

• cdo.tar.gz (2K)