On 2025/09/04 12:47, 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.
yes, formatting for WANTLIB and LIB_DEPENDS are the wrong way round here ;) (split CONFIGURE_ARGS one-per-line too, please) > 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. it's not just set to clang though, it's CC=clang-19 CXX="clang++-19" which is the ports clang (but there's no build dep on it). Is that actually still needed now that base has moved to LLVM 19? (If it needs the ports one, it should use MODULES=clang, either way it shouldn't need to hardcode the compiler names in the port). > and if the build requires egfortran, then there should be a > BUILD_DEPENDS on a working gcc version, whatever the default is.. that would be handled with MODULES=fortran and adding fortran to COMPILER_LANGS rather than an explicit BUILD_DEPENDS. (and shouldn't need to set egfortran in CONFIGURE_ARGS; adding to COMPILER_LANGS means that you get a symlink via the COMPILER_LINKS mechanism).
