Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: [new] geo/nco
To:
Marco van Hulten <marco@hulten.org>
Cc:
Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Date:
Sat, 6 Dec 2025 15:34:36 +0000

Download raw body.

Thread
On 2025/12/06 14:31, Marco van Hulten wrote:
> On Sat Dec 6, 2025 at 8:33 AM CET, Landry Breuil wrote:
> > Le Fri, Dec 05, 2025 at 09:57:54PM +0100, Marco van Hulten a écrit :
> >> On Fri Dec 5, 2025 at 6:41 PM CET, Landry Breuil wrote:
> >> > Le Fri, Dec 05, 2025 at 05:42:35PM +0100, Marco van Hulten a écrit :
> >> >> With NCO you can manipulate and analyse netCDF and similar files.  It is
> >> >> a useful addition to to tools that are already there.
> >> >> 
> >> >> So you could do this:
> >> >> 
> >> >>   wget https://cluster.klima.uni-bremen.de/~fmaussion/teaching/climate/CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc
> >> >>   ncdump -h CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc | head
> >> >>   ncrename -d month,mo CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc
> >> >>   ncdump -h CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc | head
> >> >> 
> >> >> to rename the time axis.
> >> >> 
> >> >> Apropos, geo/cdo has some of the same functionality, but it is designed
> >> >> to handle data variables, not meta information like axes names, so
> >> >> geoscientists will quickly be looking for something like NCO.
> >> >> 
> >> >> OK to add this?
> >> >
> >> > from a first look, you'll need at least fixing the proper versionning
> >> > for the @so that should be @lib with the version, and a BDEP on
> >> > print/texinfo.
> >> >
> >> > @so lib/libnco-5.3.6.so -> that doesnt use the 0.0 from SHARED_LIBS.
> >> 
> >> I added print/texinfo (and see that this is needed).  I see that this is
> >> in pkg/PLIST.  There are no @lib entries.  Does that mean I do not need
> >> to include SHARED_LIBS?
> >
> > well, it depends on what is the usecase for libnco. If it's a library
> > that's dlopened by binaries (eg generally what's called 'plugin') then
> > it can be a .so without versioning, but if it's a library things link
> > against (eg consumers of an api provided by the library) then the build
> > system should be adapted so that it is properly versionned with the
> > version coming from SHARED_LIBS, and available i nthe build env as a
> > variable (eg ${LIBnco_VERSION} iirc)
> 
> I don't think there is any software besides NCO that links to libnco, so
> what I sent yesterday at 09:57:54PM +0100 without the SHARED_LIBS should
> be right.

...new tar attached addressing most of my comments below;

also

warning: library filename /usr/obj/ports/nco-5.3.6/build-amd64/src/nco/.libs/libnco-5.3.6.so has no version number

and

-rw-r--r--   1 _pbuild  _pbuild  1649976 Dec  6 14:53 libnco-5.3.6.so
-rw-r--r--   1 _pbuild  _pbuild  2824108 Dec  6 14:53 libnco.a
-rw-r--r--   1 _pbuild  _pbuild     1293 Dec  6 14:53 libnco.la
lrwxr-xr-x   1 _pbuild  _pbuild       15 Dec  6 14:53 libnco.so -> libnco-5.3.6.so

that symlink shouldn't be there

: COMMENT =		NCO manipulates and analyses data stored in netCDF format

generally don't repeat the name of the software here, you already know
the port/package name when you see that information.

how about this instead?

CLI tools to manipulate and analyse netCDF/HDF/DAP data

: V = 			5.3.6
: DISTNAME =		nco-$V
: 
: DIST_TUPLE +=		github nco nco $V .

no benefit to the extra vars here; that can be written as

DIST_TUPLE +=		github nco nco 5.3.6 .

: BUILD_DEPENDS =		print/texinfo
: LIB_DEPENDS =		archivers/libaec \
: 			devel/gsl \
: 			math/netcdf \
: 			math/hdf5 \
: 			math/udunits \
: 			textproc/libxml \
: 			devel/gettext

deps go lower in the Makefile (near the CONFIGURE lines is common)

: # Newer version of GNU texinfo than the one in base (4.8) is needed

the comment is pretty much implied by using ports texinfo

: MAKEINFO =		"${LOCALBASE}/bin/gmakeinfo"

that isn't passed through to the build, so it's doing nothing

also prefer not to patch the generated configure script directly; unless
it's very difficult to do so it's better to patch the input files and
regen configure etc.

- upstreams description used in pkg/DESCR seems rather blurb-y
and doesn't make much sense, I borrowed the rather better description
from https://nco.sourceforge.net/#Definition instead

not covered by my updated tar - any idea what this is about or whether
it's important? (I checked and it's not due to setting SEPARATE_BUILD)

/usr/obj/ports/nco-5.3.6/build-amd64/src/nco/ncks -O -7 --cnk_dmn time,10 in.nc in_4c.nc
gmake[2]: /usr/obj/ports/nco-5.3.6/build-amd64/src/nco/ncks: No such file or directory