HYRAX-2043, make the build_dmrpp_h4 always save the eos projection du…#1282
HYRAX-2043, make the build_dmrpp_h4 always save the eos projection du…#1282
Conversation
…mmy variable value in the dmrpp file.
…e to the dmrpp file rather than the side-car file. 2) Update the testsuite to the dmrpp module. 3) Add tests to the fileout netCDF.
| @@ -1,8 +1,8 @@ | |||
| <?xml version="1.0" encoding="ISO-8859-1"?> | |||
| <Dataset xmlns="http://xml.opendap.org/ns/DAP/4.0#" xmlns:dmrpp="http://xml.opendap.org/dap/dmrpp/1.0.0#" dapVersion="4.0" dmrVersion="removed" name="grid_2_2d_sin.h5" dmrpp:href="OPeNDAP_DMRpp_DATA_ACCESS_URL" dmrpp:version="3.21.1"> | |||
| <Dataset xmlns="http://xml.opendap.org/ns/DAP/4.0#" xmlns:dmrpp="http://xml.opendap.org/dap/dmrpp/1.0.0#" dapVersion="4.0" dmrVersion="2.0" name="grid_2_2d_sin.h5" dmrpp:href="OPeNDAP_DMRpp_DATA_ACCESS_URL" dmrpp:version="3.21.1"> | |||
There was a problem hiding this comment.
For some tests with DMR documents, we started using 'dmrVersion=remvoed' because the code could make version 1.0 or 2.0 documents and we wanted the tests to not flag one or the other as an error. The test macros were 'special' to enable that. I'm not sure if that will matter here. I'm not planning in a version number change for the DMR, but I thought I'd mention the feature of the test macros just in case it's something you want to use.
There was a problem hiding this comment.
@jgallagher59701 Thanks for sharing the version number issue. I do understand the issue of version 1.0 and 2.0. I was not aware of the change of dmrVersion from 2.0 to removed. How does this 'dmrVersion=removed' be generated with build_dmrpp? It seems that this is manually changed and it should only affect the BES tests. Am I right? For the current unit tests, the version number doesn't matter since the diff of the baseline files skip the first few lines because of different BES and libdap versions.
There was a problem hiding this comment.
@jgallagher59701 Another question, this PR doesn't pass the macos and macOS-intel tests. Can I go ahead to merge to the master?
There was a problem hiding this comment.
We should get the OSX builds working.
How is 'dmrVersion=removed' generated with build_dmrpp? It doesn't get generated by the build_dmrpp code. It is set by the test code that makes the baseline file. In the test macros (the ones like AT_BESCMD_TEST(), ...) we added lines to look for the pattern 'dmrVersion=...' and replace the version number with 'removed' in the generated baseline. Then in the same macro, when it is used for a test, we filter the output of the commands to make the same substitution.
For your test it probably makes no difference, but I thought I would mention it because it might matter someday.
There was a problem hiding this comment.
Looking at the OSX build output, I think there is a problem we need to fix:
gcc -std=gnu23 -DHAVE_CONFIG_H -I. -I../../../.. -I./../include/ -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/openssl/include -I/Users/runner/install/deps/include -fpic -Wno-implicit-function-declaration -g -O2 -c -o gctp.o gctp.c
gcc -std=gnu23 -DHAVE_CONFIG_H -I. -I../../../.. -I./../include/ -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/openssl/include -I/Users/runner/install/deps/include -fpic -Wno-implicit-function-declaration -g -O2 -c -o alberfor.o alberfor.c
gcc -std=gnu23 -DHAVE_CONFIG_H -I. -I../../../.. -I./../include/ -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/openssl/include -I/Users/runner/install/deps/include -fpic -Wno-implicit-function-declaration -g -O2 -c -o alberinv.o alberinv.c
gcc -std=gnu23 -DHAVE_CONFIG_H -I. -I../../../.. -I./../include/ -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/openssl/include -I/Users/runner/install/deps/include -fpic -Wno-implicit-function-declaration -g -O2 -c -o alconfor.o alconfor.c
gcc -std=gnu23 -DHAVE_CONFIG_H -I. -I../../../.. -I./../include/ -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/openssl/include -I/Users/runner/install/deps/include -fpic -Wno-implicit-function-declaration -g -O2 -c -o alconinv.o alconinv.c
gctp.c:75:6: error: unknown type name 'incoor'
75 | gctp(incoor,insys,inzone,inparm,inunit,indatum,ipr,efile,jpr,pfile,outcoor,
| ^
gctp.c:75:13: error: unknown type name 'insys'
75 | gctp(incoor,insys,inzone,inparm,inunit,indatum,ipr,efile,jpr,pfile,outcoor,
| ^
gctp.c:75:19: error: unknown type name 'inzone'; did you mean 'inline'?
75 | gctp(incoor,insys,inzone,inparm,inunit,indatum,ipr,efile,jpr,pfile,outcoor,
| ^~~~~~
| inline
gctp.c:75:19: error: 'inline' can only appear on functions
gctp.c:75:25: error: a type specifier is required for all declarationsWhen we run the compile using gcc -std=gnu23 that might not be what we want. I'm not completely sure what the GNU 2023 'standard' version of C/C++ is, but we are using -std=14. Without looking in more detail, I have no idea why this is failing to build, but if this does not work, it's likely it will fail to build for other people.
There was a problem hiding this comment.
Looking at the other OSX build, it seems that failed because the getdapTest failed. Odd.
I restarted the builds, lets see how that goes.
…th other tests although it doesn't matter for the curent tests. Also remove the lines to handle the spurious tests on MacOS and MacOS-Intel github action builds in the python test script. Those may cause the IndexError.
|
|
|
2 participants
…mmy variable value in the dmrpp file.
Description
Reference ticket: HYRAX-2043
Tasks