Hi Charlie, I'm just jumping in on top of Russ's last email. It seems like we might have an easier short-term solution. Currently the information for the version number and the capabilities of the library (since many capabilities like dap, netcdf-4, etc. are optional) can be accessed two ways: 1. By parsing the output of `nc-config --all` (or even parse the 'nc-config' file directly). You can alternatively query nc-config for specific things, e.g. $ nc-config --version $ nc-config --has-nc4 etc. 2. Starting with the 4.3.3 release candidate, netcdf creates a file 'libnetcdf.settings' which is installed alongside the netcdf library. This file can also be parsed, and contains additional information above 'nc-config' such as the 'configured on' date. Out of curiosity, is this determination of netcdf capabilities needed at configure time or runtime? If the former, and if you are using autotools for your build system, you can have it query the netcdf library for the presence of specific functions. For example, after locating the hdf5 library with AC_SEARCH_LIBS, we use the following stanzas in our configure.ac to determine whether or not libhdf5 was built with parallel IO support: AC_CHECK_FUNCS([H5Pget_fapl_mpiposix H5Pget_fapl_mpio H5Pset_deflate H5Z_SZIP]) # The user may have parallel HDF5 based on MPI POSIX. if test "x$ac_cv_func_H5Pget_fapl_mpiposix" = xyes; then AC_DEFINE([USE_PARALLEL_POSIX], , [if true, compile in parallel netCDF-4 based on MPI/POSIX]) fi # The user may have parallel HDF5 based on MPI mumble mumble. if test "x$ac_cv_func_H5Pget_fapl_mpio" = xyes; then AC_DEFINE([USE_PARALLEL_MPIO], , [if true, compile in parallel netCDF-4 based on MPI/IO]) fi There is also a way to incorporate a shell script in configure.ac which could be used to parse libnetcdf.settings for the version. I was sure I had done this (to mirror functionality in our cmake-based build) to enforce a minimum libhdf5 version but I see now that it's not in there. So, I will need to redo this. The problem with adding NC_HAVE_* in netcdf.h is that it would turn netcdf.h into a generated file instead of a static file, which could become problematic as it would just grow and grow over time as we add additional functionality. Plus, it would duplicate symbols already tracked in the internal non-distributed 'config.h' file, which would case problems on the development side. Would parsing the extant nc-config or libnetcdf.settings work? -Ward > Hi Charlie, > > > Now that NCF-272 is fixed, I would like to support it in NCO. > > What is the best way? To workaround the now-solved bug, > > NCO currently avoids all chunking/compression calls on HDF4 files. > > Chunking should now be allowed on HDF4 files as long as > > NCO was built with netCDF 4.3.3+. > > So...we are in the familiar yet uncomfortable position where > > NCO needs to implement version-dependent libnetcdf.a functionality. > > > > For whatever reason, netCDF does not include a YYYYMMDD date token > > (like GCC does) nor a library version token (also like GCC) with > > which clients like NCO could implement netCDF version/date specific > > workarounds using those as pre-processor conditionals. > > In the absence of version/date tokens, the next easiest way for us is if > > netcdf.h includes a function-specific indicator token, e.g., > > NC_HAVE_HDF4_CHUNKING > > NC_HAVE_HDF4_DEFLATE > > Would macros such as the__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ > described at > > https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html > > suffice for what NCO needs (substituting "NETCDFC" for "GNUC" in the > macro names), or do you have a better suggestion? It seems that just > having a version string wouldn't work very well, becasue youy want o > know whwther the current version is later than a specific version, and > the approach with the macros above allows this. The alternative of a > version date integer such as YYYYMMDD would require developers to know > about the correspondence between version numbers and release dates, so > I'd prefer not to use that. > > > Also, it is unclear if netCDF-HDF4 now supports compression > > inquiry and/or setting functions. When I filed the original > > bug report nc_inq_var_deflate() would crash on HDF4. Does it still? > > Not sure, we'll have to get back to you on that. > > > It would be great if such library hints could be in 4.3.3-final. > > If it's just a matter of defining them in netcdf.h for this and all > subsequent releases, we can do that. We'd define them manually > for this release and automate it as part of the release management > from now on. > > --Russ > > > Thanks, > > Charlie > > -- > > Charlie Zender, Earth System Sci. & Computer Sci. > > University of California, Irvine 949-891-2429 )'( > > > > > > Russ Rew UCAR Unidata Program > address@hidden http://www.unidata.ucar.edu > > Ticket Details =================== Ticket ID: IJX-817619 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.