On Sat Dec 6, 2025 at 4:34 PM CET, Stuart Henderson wrote:
> 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

Yes, that is fine.

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

Yes, this is nicer.  I removed patch-configure and things still work
fine as we autogen now.

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

That is much better description indeed!

> 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

There are more of such stderr messages during build about files not
existing (both scripts and data files), but they do exist when I look.
I'll report these and the rest I see in stderr upstream.

ncks(1) works fine when running it from the command line, both script
/home/_ports/pobj/nco-5.3.6/build-amd64/src/nco/ncks and the installed
binary /usr/local/bin/ncks.

I think it is fine to commit.  In the tarball attached the only change
is the removal of patch/patch-configure w.r.t. your last tarball.

 Marco

• nco.tar.gz (2K)