eccodes

eccodes

[brendan detracey]

Hi,
eccodes builds out of the box, more or less. However, all tests fail because the cyg*.dll's weren't copied to ${B}/bin. (They were handled properly when built without cygport i.e. copied from src and fortran subdirs of the build dir.)
What have I done wrong?
Apologies for cut and paste. I have yet to learn git. It is on the list... 

Finally, is there template for passing the number of processors minus 1 to cygport for all compiling and testing? If so, will cygport pass it automatically through cygcmake to its makefile generator and to cygtest? It would be nice to speed up my compile.
Thanks,Brendan

eccodes.cygport-----------------------------------------------------------------------------------inherit cmake
shopt -s extglob
# WARNING: source download link has to be hard-coded :(# The eccodes cmake default install location is usr/local
NAME="eccodes"VERSION=2.21.0RELEASE=1
CATEGORY="Science"SUMMARY="ECMWF tools to decode and encode WMO GRIB and BUFR file formats, and decode WMO GTS file format"DESCRIPTION="ecCodes is a package developed by ECMWF which provides an API and a set of tools\ for decoding and encoding messages in the following formats\:\ WMO FM-92 GRIB edition 1 and edition 2\ WMO FM-94 BUFR edition 3 and edition 4\  WMO GTS abbreviated header (only decoding)"
HOMEPAGE="https://confluence.ecmwf.int/display/ECC/ecCodes+Home"SRC_URI="https://confluence.ecmwf.int/download/attachments/45757960/eccodes-2.21.0-Source.tar.gz" SRC_DIR="${PN}-${PV}-Source"
PKG_NAMES="eccodes libeccodes libeccodes-devel"
eccodes_CONTENTS="  usr/local/bin/!(cyg*dll)  usr/local/share"
libeccodes_CATEGORY="Libs"libeccodes_SUMMARY="${SUMMARY} (runtime)"libeccodes_CONTENTS="  usr/local/bin/cyg*dll"
libeccodes_devel_CATEGORY="Libs"libeccodes_devel_SUMMARY="${SUMMARY} (development)"libeccodes_devel_CONTENTS="  usr/local/lib/  usr/local/include"
RESTRICT="diff"KEEP_LA_FILES="none"
# curl is required to download full test data set from ECMWF. Will this behave under CI?BUILD_REQUIRES="curl gfortran libnetcdf-devel libopenjpeg-devel libpng-devel libaec-devel libgomp1"
CYGCMAKE_GENERATOR="Unix Makefiles"CYGCMAKE_ARGS="    -DDISABLE_OS_CHECK=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DIEEE_LE=1    -DENABLE_NETCDF=ON -DENABLE_JPG_LIBOPENJPEG=ON -DENABLE_PNG=ON -DENABLE_AEC=ON -DENABLE_FORTRAN=ON -DENABLE_ECCODES_OMP_THREADS=ON -DENABLE_MEMFS=OFF -DENABLE_EXTRA_TESTS=ON"

Re: eccodes

[Achim Gratz]

brendan detracey via Cygwin-apps writes:
> eccodes builds out of the box, more or less. However, all tests fail
> because the cyg*.dll's weren't copied to ${B}/bin. (They were handled
> properly when built without cygport i.e. copied from src and fortran
> subdirs of the build dir.)

Hard to say without a log why that happens, but you should start with
checking whether the copy is even attempted.

> Finally, is there template for passing the number of processors minus
> 1 to cygport for all compiling and testing? If so, will cygport pass
> it automatically through cygcmake to its makefile generator and to
> cygtest? It would be nice to speed up my compile.

Cygport will by default set MAKEOPTS to "-jN ", with N=1+nproc.  I am
not sure that will automatically be used by cmake.

> eccodes.cygport-----------------------------------------------------------------------------------
> inherit cmake

Whatever you are using to send your mails is mangling text pretty
badly.

> shopt -s extglob
> # WARNING: source download link has to be hard-coded :(

You can use the variables that are defined, but I guess you meant the
stupid attachment ID from Confluence (no, putting source code into a
Wiki is not a goos idea for many other reasons).

> # The eccodes cmake default install location is usr/local

If you package it officially that needs to change, /usr/local is
off-limits for packages.

> NAME="eccodes"
> VERSION=2.21.0
> RELEASE=1
> CATEGORY="Science"
> SUMMARY="ECMWF tools to decode and encode WMO GRIB and BUFR file
> formats, and decode WMO GTS file format"
> DESCRIPTION="ecCodes is a package developed by ECMWF which provides an API and a set of tools\ for decoding and encoding messages in the following formats\:\ WMO FM-92 GRIB edition 1 and edition 2\ WMO FM-94 BUFR edition 3 and edition 4\  WMO GTS abbreviated header (only decoding)"
> HOMEPAGE="https://confluence.ecmwf.int/display/ECC/ecCodes+Home"SRC_URI="https://confluence.ecmwf.int/download/attachments/45757960/eccodes-2.21.0-Source.tar.gz"
> SRC_DIR="${PN}-${PV}-Source"

${PN}-${PV} == ${P}

> PKG_NAMES="eccodes libeccodes libeccodes-devel"
> eccodes_CONTENTS="  usr/local/bin/!(cyg*dll)  usr/local/share"
> libeccodes_CATEGORY="Libs"
> libeccodes_SUMMARY="${SUMMARY} (runtime)"
> libeccodes_CONTENTS="  usr/local/bin/cyg*dll"
> libeccodes_devel_CATEGORY="Libs"
> libeccodes_devel_SUMMARY="${SUMMARY} (development)"
> libeccodes_devel_CONTENTS="  usr/local/lib/  usr/local/include"
> RESTRICT="diff"
> KEEP_LA_FILES="none"
> # curl is required to download full test data set from ECMWF. Will
> this behave under CI?

You should download that data set via SRC_URI instead so it is already
available when needed, unless it is too large to get packaged,

> BUILD_REQUIRES="curl gfortran libnetcdf-devel libopenjpeg-devel libpng-devel libaec-devel libgomp1"
> CYGCMAKE_GENERATOR="Unix Makefiles"
> CYGCMAKE_ARGS="    -DDISABLE_OS_CHECK=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DIEEE_LE=1    -DENABLE_NETCDF=ON -DENABLE_JPG_LIBOPENJPEG=ON -DENABLE_PNG=ON -DENABLE_AEC=ON -DENABLE_FORTRAN=ON -DENABLE_ECCODES_OMP_THREADS=ON -DENABLE_MEMFS=OFF -DENABLE_EXTRA_TESTS=ON"


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: eccodes

[Brian Inglis]

On 2021-04-11 12:01, Achim Gratz wrote:
> brendan detracey via Cygwin-apps writes:
>> eccodes builds out of the box, more or less. However, all tests fail
>> because the cyg*.dll's weren't copied to ${B}/bin. (They were handled
>> properly when built without cygport i.e. copied from src and fortran
>> subdirs of the build dir.)
> 
> Hard to say without a log why that happens, but you should start with
> checking whether the copy is even attempted.

DLLs should be built in $B/.../, installed in $D/bin/, and the tests have to run 
with $D/bin/ in their path.
Not sure if this is automatic, you may have to override src_test, or patch the 
test setup to add that.

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

Re: eccodes

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On 11.04.2021 20:53, Brian Inglis wrote:
> On 2021-04-11 12:01, Achim Gratz wrote:
>> brendan detracey via Cygwin-apps writes:
>>> eccodes builds out of the box, more or less. However, all tests fail
>>> because the cyg*.dll's weren't copied to ${B}/bin. (They were handled
>>> properly when built without cygport i.e. copied from src and fortran
>>> subdirs of the build dir.)
>>
>> Hard to say without a log why that happens, but you should start with
>> checking whether the copy is even attempted.
> 
> DLLs should be built in $B/.../, installed in $D/bin/, and the tests 
> have to run with $D/bin/ in their path.
> Not sure if this is automatic, you may have to override src_test, or 
> patch the test setup to add that.
> 

Brendan,
no idea why on your build the installation is under /usr/local
for me everything is in the right place.
Please verify if you have some settings interfering

Attached version that allows tests to be passed

Regards
Marco


[-- Attachment #2: eccodes.cygport --]
[-- Type: text/plain, Size: 1722 bytes --]

inherit cmake
shopt -s extglob
# WARNING: source download link has to be hard-coded :(# The eccodes cmake default install location is usr/local
NAME="eccodes"
VERSION=2.21.0
RELEASE=1
CATEGORY="Science"
SUMMARY="ECMWF tools to decode and encode WMO GRIB and BUFR file formats, and decode WMO GTS file format"
DESCRIPTION="ecCodes is a package developed by ECMWF which provides an API and a set of tools\ for decoding and encoding messages in the following formats\:\ WMO FM-92 GRIB edition 1 and edition 2\ WMO FM-94 BUFR edition 3 and edition 4\  WMO GTS abbreviated header (only decoding)"
HOMEPAGE="https://confluence.ecmwf.int/display/ECC/ecCodes+Home"
SRC_URI="https://confluence.ecmwf.int/download/attachments/45757960/eccodes-2.21.0-Source.tar.gz" 
SRC_DIR="${PN}-${PV}-Source"
PKG_NAMES="eccodes libeccodes libeccodes-devel"
eccodes_CONTENTS="  usr/bin/!(cyg*dll)  usr/share"
libeccodes_CATEGORY="Libs"
libeccodes_SUMMARY="${SUMMARY} (runtime)"
libeccodes_CONTENTS="  usr/bin/cyg*dll"
libeccodes_devel_CATEGORY="Libs"
libeccodes_devel_SUMMARY="${SUMMARY} (development)"
libeccodes_devel_CONTENTS="  usr/lib/  usr/include"
RESTRICT="diff"
KEEP_LA_FILES="none"
# curl is required to download full test data set from ECMWF. Will this behave under CI?
BUILD_REQUIRES="curl gfortran libnetcdf-devel libopenjpeg-devel libpng-devel libaec-devel libgomp1"
CYGCMAKE_GENERATOR="Unix Makefiles"
CYGCMAKE_ARGS="    -DDISABLE_OS_CHECK=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DIEEE_LE=1    -DENABLE_NETCDF=ON -DENABLE_JPG_LIBOPENJPEG=ON -DENABLE_PNG=ON -DENABLE_AEC=ON -DENABLE_FORTRAN=ON -DENABLE_ECCODES_OMP_THREADS=ON -DENABLE_MEMFS=OFF -DENABLE_EXTRA_TESTS=ON"


src_test() {
	PATH=${B}/src:${PATH}
	cd ${B}
	cygmake test
}
	

Re: eccodes

[brendan detracey]

That worked Marco. Thanks guys!How did "cygmake test" know it had to call "ctest"? In the eccodes instructions, "ctest" is the command. 

Why doesn't cygport automatically symlink the cyg*dll files for tests?


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

    On Sunday, April 11, 2021, 04:43:41 p.m. ADT, Marco Atzeri via Cygwin-apps <cygwin-apps@cygwin.com> wrote:  
 
 On 11.04.2021 20:53, Brian Inglis wrote:
> On 2021-04-11 12:01, Achim Gratz wrote:
>> brendan detracey via Cygwin-apps writes:
>>> eccodes builds out of the box, more or less. However, all tests fail
>>> because the cyg*.dll's weren't copied to ${B}/bin. (They were handled
>>> properly when built without cygport i.e. copied from src and fortran
>>> subdirs of the build dir.)
>>
>> Hard to say without a log why that happens, but you should start with
>> checking whether the copy is even attempted.
> 
> DLLs should be built in $B/.../, installed in $D/bin/, and the tests 
> have to run with $D/bin/ in their path.
> Not sure if this is automatic, you may have to override src_test, or 
> patch the test setup to add that.
> 

Brendan,
no idea why on your build the installation is under /usr/local
for me everything is in the right place.
Please verify if you have some settings interfering

Attached version that allows tests to be passed

Regards
Marco

  

Re: eccodes

[Marco Atzeri]

Brendan,
Bottom post on Cygwin mailing lists, please

On 11.04.2021 23:53, brendan detracey via Cygwin-apps wrote:
> That worked Marco. Thanks guys!How did "cygmake test" know it had to call "ctest"? In the eccodes instructions, "ctest" is the command.

It is on the makefile

-------------------------------------------------------------------
# Special rule for the target test
test:
         @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --cyan 
"Running tests..."
         /usr/bin/ctest.exe --force-new-ctest-process $(ARGS)
.PHONY : test
-------------------------------------------------------------------

> Why doesn't cygport automatically symlink the cyg*dll files for tests?

It should be upstream instruction for testing where to find the
shared lib or they are expecting to test after installation.
It is not a problem with automake/autoconf as it is managed properly.

This workaround is relative common in these cases


>      On Sunday, April 11, 2021, 04:43:41 p.m. ADT, Marco Atzeri via Cygwin-apps wrote:

> 
> Brendan,
> no idea why on your build the installation is under /usr/local
> for me everything is in the right place.
> Please verify if you have some settings interfering
> 
> Attached version that allows tests to be passed
> 
> Regards
> Marco
> 
>    
> 

Re: eccodes

[Achim Gratz]

[please keep your answers on the list]

>> You should download that data set via SRC_URI instead so it is already
>> available when needed, unless it is too large to get packaged,
>>
> Thanks. Are you are saying I should add script to download the file in
> function src_test? Or add its URI as a value in the cygport file? What
> would the variable name be for that?

As I said already: SRC_URI.  You can put multiple URI there and they
will all be fetched and unpacked before you enter the build procedure.

>[I am using yahoo mail through a
> browser and I can't find a setting for unformatted text.]

It never ceases to amaze me that after all those years they still don't
manage to make (or even just use) a decent web mailer.  Reading and
answering your mail via a local mail program is not an option for you?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: eccodes

[Brian Inglis]

On 2021-04-12 13:22, Achim Gratz wrote:
>> [I am using yahoo mail through a browser and I can't find a setting for
>> unformatted text.]
> It never ceases to amaze me that after all those years they still don't 
> manage to make (or even just use) a decent web mailer.  Reading and answering
> your mail via a local mail program is not an option for you?
Look at your friends and relatives email addresses. It is apparent that most 
people (without tech ability or in-house support - us!) just use:

* whatever comes installed on or is available with their phone;

* web mail client available from their ISP (if they have or use one) and if any 
web mail client is offered; or

* web mail client provided by some web site (like CompuServe -> AOL + Yahoo! -> 
Oath -> Verizon Media) if their ISP provided no interface (not even Outlook Web 
Access) and required each customer to buy and install their own mail client;

* along with using the associated default locked in email accounts.

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