Charlie, > Yes, those tokens would suffice for most purposes. Shortly after sending my earlier response, I discussed this with Ward and realized that the version information doesn't help to determine with which features the netCDF library was configured and built. But the new lib/library.settings file already includes all the needed information about how the library was configured as well as what version of the source was used. So I'm now convinced that it would be better not to have to generate different netcdf.h files for different library versions, if we can avoid it. We've tried to make the library.settings file easily parseable, so the information can be extracted with simple shell commands. > We would like to use them thusly: > > #if (__GNUC__ * 100 + __GNUC_MINOR__ * 10 + __GNUC_PATCHLEVEL__ ) < 442 > > That works as long as Unidata keeps each token < 10. > > The exception is when Unidata puts a new feature in > the daily snapshot. Versioning has to be done > carefully in order to test new features. > Bumping PATCHLEVEL since the last stable release > would handle most situations. Or some other way to tell > it's different than the last stable release. > > The entire macro above needs to be well-behaved on > older libraries, so we would probably implement > something at the start like > #ifndef __GNUC__ > # define __GNUC__ 3 > # define __GNUC_MINOR__ 6 > ... We are still discussing this, and the issues are more complex than my original, somewhat superficial, response took into account. Just adding version indicators to netcdf.h no longer seems like something we can support. It would involve reworking our infrastructure to provide another way of getting at information that we're already making available, in the new libnetcdf.settings file. --Russ > Best, > Charlie > > On 08/29/2014 08:50 AM, Unidata netCDF Support wrote: > > 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 > > > > -- > 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.