Index | Thread | Search

From:
"Marco van Hulten" <marco@hulten.org>
Subject:
Re: [new] geo/nco
To:
"Landry Breuil" <landry@openbsd.org>
Cc:
<ports@openbsd.org>
Date:
Sat, 06 Dec 2025 14:31:37 +0100

Download raw body.

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

 Marco