[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #IJX-817619]: HDF4 chunking (and compression?) support hints

Hi Charlie,

We had our netcdf meeting today and spent some time discussing this very
issue, and have come to a similar conclusion.

Including this information in netcdf.h would be problematic from a
mechanical standpoint; dynamically generated content is handled differently
by the autotools and cmake build systems. In addition to this, I understand
from Russ and Dennis that we have used a dynamically generated netcdf.h in
the past, which caused some issues.

Instead, I am currently working on generating a ânetcdf_meta.hâ (name
subject to change) header file dynamically at configure time; this file
will include information related to the capabilities of the library
(#define NC_HAS_NC2, #define NC_HAS_NC4, etc). Once this is complete, we
will define something along the lines of #NC_HAS_NETCDF_META in netcdf.h so
that developers can determine if this meta header file exists and include
it when it does.

Iâm hoping to have this done relatively soon, but my plate is pretty full
for the next week or so. It will be in the 4.3.3 release for sure (famous
last words), and will even be in the 4.3.3-rc2 if at all possible.

Anyways, itâs good to see we have come to similar conclusions and that it
sounds like it will provide the functionality you are looking for! Iâll
make sure to let you know when I have the first pass at generating this
file completed.

Have a great evening,


address@hidden> wrote:

New Client Reply: HDF4 chunking (and compression?) support hints
> Hi Dennis, Ward, and Russ,
> Let me clarify something:
> As you know I prefer some CPP/netcdf.h method
> be used to convey libnetcdf version or capability info to applications.
> This would allow applications to make version-specific
> choices for algorithms (like whether the HDF4 chunking patch might be
> supported).
> However, it does not tell applications whether netCDF
> was built with HDF4 support (like nc-config --has-hdf4).
> This is something that requires
> more that a pure version number to determine. It requires
> knowledge of the build-time parameters of libnetcdf.a.
> Whether such build-time tokens, e.g., NC_HAVE_HDF4, can/should
> be placed in netcdf.h is not something I have opined about.
> Until now :)
> In my opinion such tokens should be in netcdf.h.
> Each instance of netcdf.h is already inextricably linked with
> the corresponding libnetcdf.a. I can think of no compelling
> reason why all netcdf.h's should be identical when their
> corresponding libraries differ.
> Yes, this would mean one netcdf.h for version 4.3.3
> could differ from another netcdf.h for version 4.3.3,
> because one has NC_HAVE_HDF4=1 and the other does not.
> Some folks would argue against this.
> In my view it's not a big deal.
> As far as proliferation of tokens goes, it's tiny.
>   If Unidata adds a token or two to netcdf.h each release
> it would take years or decades before it increased netcdf.h by 1 kB.
> We long ago passed the point where 1 kB was insignificant.
> And it is clearer when all build information is in one place.
> To be clear, addding GCC_VERSION-style tokens to netcdf.h
> is logically segregable from adding tokens to indicated
> all features in libnetcdf.a. Were I asked, I would
> advocated adding tokens for both situations.
> Sincerely,
> Charlie
> On 09/02/2014 08:05 AM, Unidata netCDF Support wrote:
> > Charlie, I have a question.
> > There are 3 obvious places where one
> > might require knowledge of e.g. the version number.
> > 1. At build time. That is in the cmake|makefile|./configure
> > code, one might need the version no.
> > 2. At compile time. THis would generally require
> >     using some file like netcdf.h that has the version
> >     defined as a #define macro.
> > 3. At run time. The client program would query the
> >     netcdf library for the version info.
> >
> > Judging by your comments, I am assuming that you
> > want #2 - compile time access. Of course, this
> > also as a rule requires #1 so that e.g. netcdf.h
> > can be properly generated at build time.
> >
> > 2 question:
> > 1. am I right in assuming you want the info at compile time
> > 2. what build system (if any) are you currently using for NCO
> >
> > =Dennis Heimbigner
> >    Unidata
> >
> >
> > 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 )'(
> Ticket Details
> ===================
> Ticket ID: IJX-817619
> Department: Support netCDF
> Priority: Normal
> Status: Open
> Link:
> https://www.unidata.ucar.edu/esupport/staff/index.php?_m=tickets&_a=viewticket&ticketid=24361
>  â

Ticket Details
Ticket ID: IJX-817619
Department: Support netCDF
Priority: Normal
Status: Open

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.