Proposal to package eecodes + four short cygport questions + a comment

Proposal to package eecodes + four short cygport questions + a comment

[brendan detracey]

Hi,
I would like to maintain a package for eccodes (https://confluence.ecmwf.int/display/ECC/ecCodes+Home), which is used to process the GRIB weather data format. It is an "optional" prerequisite for cdo  (climate data operators https://code.mpimet.mpg.de/projects/cdo ) , a very powerful climate data command line tool which I would also like to port, pending success with eccodes.
These are somewhat niche applications but are widely used in the earth sciences communities. Anecdotally, there are still people who rely on cygwin to run them, likely because their corporate masters have them trapped using Windows without the admin rights to install either a VM, or WSL1/2. 
The eccodes license is Apache License V2. It builds and tests successfully with cmake. No patching required. All I have to do is write the cygport file.
I get the gist of cygports, but I do not understand the following:
1. After manually installing eccodes myself, its lib folder contains:$ ls lib
cmake/  libeccodes.dll.a  libeccodes_f90.dll.a  pkgconfig/Will I have to add exclusions for the cmake and pkgconfig directories? Or does cygcmake take care of this?
2. Do I understand correctly that I will not have to populate REQUIRES/PKG_REQUIRES in most cases? 
3. PKG_CONTENTS is the manually populated list of files to install?
4. BUILD_REQUIRES is the manually populated list of development packages required to build?
A comment. Took me a day to realize all the cygport examples I would ever need could be found by installing source packages. This is stated indirectly in the "Making a package with cygport" section of package contributors guide .  It would be helpful if it was more explicitly stated. For example, "The cygport file for any cygwin package may be found in /usr/src/package_name after installing the package source using setup-x86_64.exe". It may seem superfluous to those who already know, but to numpties like myself...
So much thanks to the cygwin community, past and present, who kept me productive and sane at work whilst my erstwhile corporate masters made me work 100% on Windows without any admin rights. Dark days indeed.


-------------------------- brendandetracey@yahoo.com

Re: Proposal to package eecodes + four short cygport questions + a comment

[Marco Atzeri]

On 10.04.2021 21:17, brendan detracey via Cygwin-apps wrote:
> Hi,

Hi Brendan

> I would like to maintain a package for eccodes (https://confluence.ecmwf.int/display/ECC/ecCodes+Home), which is used to process the GRIB weather data format. It is an "optional" prerequisite for cdo  (climate data operators https://code.mpimet.mpg.de/projects/cdo ) , a very powerful climate data command line tool which I would also like to port, pending success with eccodes.
> These are somewhat niche applications but are widely used in the earth sciences communities. Anecdotally, there are still people who rely on cygwin to run them, likely because their corporate masters have them trapped using Windows without the admin rights to install either a VM, or WSL1/2.
> The eccodes license is Apache License V2. It builds and tests successfully with cmake. No patching required. All I have to do is write the cygport file.

you can post your cygport here and we can review it before accepting
the package

> I get the gist of cygports, but I do not understand the following:
> 1. After manually installing eccodes myself, its lib folder contains:$ ls lib
> cmake/  libeccodes.dll.a  libeccodes_f90.dll.a  pkgconfig/Will I have to add exclusions for the cmake and pkgconfig directories? Or does cygcmake take care of this?

cmake you can exclude, pkgconfig you should leave
All should go in a cdo-devel package, as like:

$ cygcheck -l libnetcdf-devel | grep lib
/usr/lib/libnetcdf.dll.a
/usr/lib/libnetcdf.settings
/usr/lib/pkgconfig/netcdf.pc

> 2. Do I understand correctly that I will not have to populate REQUIRES/PKG_REQUIRES in most cases?

Usually not needed.
Add only packages that you notice are missing from the
cygport detection.


> 3. PKG_CONTENTS is the manually populated list of files to install?
is the list of installed files that you want in a specific package.
During the "install" phase cygport creates the tree under "inst"

> 4. BUILD_REQUIRES is the manually populated list of development packages required to build?
yes. Anything that is needed as libraries or special tools.
Compilers, make or anything in "Base" are not needed



> A comment. Took me a day to realize all the cygport examples I would ever need could be found by installing source packages. This is stated indirectly in the "Making a package with cygport" section of package contributors guide .  It would be helpful if it was more explicitly stated. For example, "The cygport file for any cygwin package may be found in /usr/src/package_name after installing the package source using setup-x86_64.exe". It may seem superfluous to those who already know, but to numpties like myself...

Noted. Maybe you can suggest a patch for:
https://cygwin.com/packaging-contributors-guide.html


> So much thanks to the cygwin community, past and present, who kept me productive and sane at work whilst my erstwhile corporate masters made me work 100% on Windows without any admin rights. Dark days indeed.
> 

Regards
Marco

Re: Proposal to package eecodes + four short cygport questions + a comment

[Brian Inglis]

On 2021-04-10 13:17, brendan detracey via Cygwin-apps wrote:
> I would like to maintain a package for eccodes (https://confluence.ecmwf.int/display/ECC/ecCodes+Home), which is used to process the GRIB weather data format. It is an "optional" prerequisite for cdo  (climate data operators https://code.mpimet.mpg.de/projects/cdo ) , a very powerful climate data command line tool which I would also like to port, pending success with eccodes.
> These are somewhat niche applications but are widely used in the earth sciences communities. Anecdotally, there are still people who rely on cygwin to run them, likely because their corporate masters have them trapped using Windows without the admin rights to install either a VM, or WSL1/2.
> The eccodes license is Apache License V2. It builds and tests successfully with cmake. No patching required. All I have to do is write the cygport file.

Welcome to our world.

> I get the gist of cygports, but I do not understand the following:

> 1. After manually installing eccodes myself, its lib folder contains:$ ls lib
> cmake/  libeccodes.dll.a  libeccodes_f90.dll.a  pkgconfig/Will I have to add exclusions for the cmake and pkgconfig directories? Or does cygcmake take care of this?
Mostly cygport Does The Right Thing, but you may have to specify variables, 
provide your own src_compile or src_install or other functions, based on the 
default(s), with additional cygport function calls to override the default 
behaviour, or provide patches to CMakeLists.txt, other upstream build 
components, or source files, etc. sometimes with Cygwin conditionals.

> 2. Do I understand correctly that I will not have to populate REQUIRES/PKG_REQUIRES in most cases?
Correct.

> 3. PKG_CONTENTS is the manually populated list of files to install?
Not normally unless you are building multiple "sub-"packages, when it's like:

	PKG_NAMES="${NAME} lib${NAME}# lib${NAME}-devel lib${NAME}-doc"

	eccodes_CONTENTS="
		...
	"
	libeccodes#_CATEGORY="$CATEGORY Libs"
	libeccodes#_SUMMARY="$SUMMARY (runtime)"
	libeccodes#_REQUIRES="..."
	libeccodes#_CONTENTS="
		...
	"
	libeccodes_devel_CATEGORY="$CATEGORY Devel Libs"
	libeccodes_devel_SUMMARY="$SUMMARY (development)"
	libeccodes_devel_REQUIRES="..."
	libeccodes_devel_CONTENTS="
		...
	"
	libeccodes_doc_CATEGORY="$CATEGORY Devel Doc"
	libeccodes_doc_SUMMARY="$SUMMARY (API docs)"
	libeccodes_doc_DOCS="
		...
	"
	libeccodes_doc_CONTENTS="
		...
	"

and please remember that cygport supports bash path file globs, including 
sub-directories, so use them where possible and supported instead of listing 
every file. This is especially helpful for packages updated multiple times a 
year where you could easily miss some added files.

> 4. BUILD_REQUIRES is the manually populated list of development packages required to build?
Correct.

Look at the variables and functions under cygport html doc chapters Compiling 
and Installing: they may be set or called to DTRT with files over and above 
those taken care of by cygport which is as helpful as possible particularly with 
autotools builds (the default).

For alternate toolchains, see the Cygclasses chapter for what to inherit to 
provide alternative variables and functions to tweak the processes.

If you can find similar packages using similar toolchains, you will get the 
flavour of how to tweak the default behaviour to do what is needed for Cygwin.

For example:
* define SRC_DIR=... if the sources are not packaged in the upstream tar file 
under the $NAME-$VERSION top level directory;
* define DOCS="
	list of files
" to install additional files under the /usr/share/doc/$NAME/ directory.

And if the package is not arch independent, as for interpreted and docs packages 
when you will have to define ARCH=noarch, you will have to install the 
BUILD_REQUIRES prereqs and run cygport builds under both x86_64 and x86 
environments (do not specify ARCH, it will default from the build environment).

You should take time to familiarize yourself with ssh{,-keygen,-agent,-add} to 
access the package server, and the cygport upload and announce commands, which 
make dealing with the package server and mailing lists easy.

> A comment. Took me a day to realize all the cygport examples I would ever need could be found by installing source packages. This is stated indirectly in the "Making a package with cygport" section of package contributors guide .  It would be helpful if it was more explicitly stated. For example, "The cygport file for any cygwin package may be found in /usr/src/package_name after installing the package source using setup-x86_64.exe". It may seem superfluous to those who already know, but to numpties like myself...

You can also find a lot of cygport and patch files from packages updated in 
recent years by most maintainers at:

	https://cygwin.com/git-cygwin-packages/

and for packages with cygport and patch files checked in there, an Appveyor CI 
instance runs jobs reported at:

	https://cygwin.com/cgi-bin2/jobs.cgi

> So much thanks to the cygwin community, past and present, who kept me productive and sane at work whilst my erstwhile corporate masters made me work 100% on Windows without any admin rights. Dark days indeed.

You may have to do some reading in cygwin-apps archives to get details of fairly 
recent cygport, calm, Appveyor CI, and other infrastructure improvements not yet 
documented in the web pages.

You may contribute patches to the web site docs at:

	https://cygwin.com/git/?p=cygwin-htdocs.git

using git format-patch/send-email to cygwin-patches mailing list.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]