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