CMake: Bring nczarr dependency when enabling S3 in line with autotools - #3149
Conversation
re: PR Unidata#3068 Affects files: * libdispatch/ncutil.[ch] * libdispatch/drc.c * include/ncutil.h * include/ncrc.h * include/netcdf_vutils.h plus any files that use the above modified .h files. Part of splitting PR 3068 1. move libdispatch/ncutil.h to include/netcdf_vutils.h and rename uses. 2. Refactor code to move and unify various functions from libdispatch/drc.c into ncutil.h and ncutil.c. 3. Modify file includes to use ncutil.h.
This reverts commit 8a4284a.
…s behavior (in support of Unidata#3122
mannreis
left a comment
mannreis
left a comment
There was a problem hiding this comment.
I left some minor suggestions to remove duplicate imports and a comment on the build that is failing. Thanks!
| # If NETCDF_ENABLE_S3 is ON/TRUE, then enable NETCDF_ENABLE_NCZARR, in order to keep | ||
| # things congruent with autotools. | ||
| if (NETCDF_ENABLE_S3) | ||
| set(NETCDF_ENABLE_NCZARR ON CACHE BOOL "Enable NCZarr Client" FORCE) | ||
| endif(NETCDF_ENABLE_S3) | ||
|
|
There was a problem hiding this comment.
I believe this is causing the build problem in: https://github.com/Unidata/netcdf-c/actions/runs/16181140174/job/45678589358?pr=3149#step:19:1518
By setting S3 on, NCZARR is turned on but it will still need HDF5/NC4 therefore failing the build with NC3.
I think the issue was with autotools only on CYGWIN, not in cmake. Going back to my pipeline: https://github.com/Unidata/netcdf-c/actions/runs/15902006750/job/44847012519#step:13:686
The libcrypto symbols were not being found when --enable-s3 and --disable-nczarr combined.
Co-authored-by: Manuel Reis <16836000+mannreis@users.noreply.github.com>
Co-authored-by: Manuel Reis <16836000+mannreis@users.noreply.github.com>
Co-authored-by: Manuel Reis <16836000+mannreis@users.noreply.github.com>
Co-authored-by: Manuel Reis <16836000+mannreis@users.noreply.github.com>
…c into s3-nczarr-cmake-ac-fix.wif
|
Just a note I am still working on this @DennisHeimbigner @mannreis. Can anybody replicate the cygwin issues locally? I'm struggling to. I'm out Monday-Wednesday, getting back midday Thursday. This blocking issue needs to be resolved before I can move on to other business, and I appreciate any thoughts. I'm sure we'll get it :) |
|
@WardF @DennisHeimbigner the problem was that the For some reason that doesn't work... I've created WardF#3 to just add You can see the output of the action from my fork: https://github.com/mannreis/netcdf-c/actions/runs/16591032738/job/46926479610. Although it fails it's because of artifact name conflict and |
3 participants
In support of #3122