* eccodes [not found] <1777022414.443732.1618159734064.ref@mail.yahoo.com> @ 2021-04-11 16:48 ` brendan detracey 2021-04-11 18:01 ` eccodes Achim Gratz 0 siblings, 1 reply; 8+ messages in thread From: brendan detracey @ 2021-04-11 16:48 UTC (permalink / raw) To: cygwin-apps 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" ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-11 16:48 ` eccodes brendan detracey @ 2021-04-11 18:01 ` Achim Gratz 2021-04-11 18:53 ` eccodes Brian Inglis 2021-04-12 19:22 ` eccodes Achim Gratz 0 siblings, 2 replies; 8+ messages in thread From: Achim Gratz @ 2021-04-11 18:01 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-11 18:01 ` eccodes Achim Gratz @ 2021-04-11 18:53 ` Brian Inglis 2021-04-11 19:43 ` eccodes Marco Atzeri 2021-04-12 19:22 ` eccodes Achim Gratz 1 sibling, 1 reply; 8+ messages in thread From: Brian Inglis @ 2021-04-11 18:53 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-11 18:53 ` eccodes Brian Inglis @ 2021-04-11 19:43 ` Marco Atzeri 2021-04-11 21:53 ` eccodes brendan detracey 0 siblings, 1 reply; 8+ messages in thread From: Marco Atzeri @ 2021-04-11 19:43 UTC (permalink / raw) To: cygwin-apps [-- 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 } ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-11 19:43 ` eccodes Marco Atzeri @ 2021-04-11 21:53 ` brendan detracey 2021-04-12 7:07 ` eccodes Marco Atzeri 0 siblings, 1 reply; 8+ messages in thread From: brendan detracey @ 2021-04-11 21:53 UTC (permalink / raw) To: cygwin-apps 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-11 21:53 ` eccodes brendan detracey @ 2021-04-12 7:07 ` Marco Atzeri 0 siblings, 0 replies; 8+ messages in thread From: Marco Atzeri @ 2021-04-12 7:07 UTC (permalink / raw) To: cygwin-apps 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 > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-11 18:01 ` eccodes Achim Gratz 2021-04-11 18:53 ` eccodes Brian Inglis @ 2021-04-12 19:22 ` Achim Gratz 2021-04-12 22:46 ` eccodes Brian Inglis 1 sibling, 1 reply; 8+ messages in thread From: Achim Gratz @ 2021-04-12 19:22 UTC (permalink / raw) To: cygwin-apps [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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: eccodes 2021-04-12 19:22 ` eccodes Achim Gratz @ 2021-04-12 22:46 ` Brian Inglis 0 siblings, 0 replies; 8+ messages in thread From: Brian Inglis @ 2021-04-12 22:46 UTC (permalink / raw) To: cygwin-apps 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.] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-04-12 22:46 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1777022414.443732.1618159734064.ref@mail.yahoo.com> 2021-04-11 16:48 ` eccodes brendan detracey 2021-04-11 18:01 ` eccodes Achim Gratz 2021-04-11 18:53 ` eccodes Brian Inglis 2021-04-11 19:43 ` eccodes Marco Atzeri 2021-04-11 21:53 ` eccodes brendan detracey 2021-04-12 7:07 ` eccodes Marco Atzeri 2021-04-12 19:22 ` eccodes Achim Gratz 2021-04-12 22:46 ` eccodes Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).