NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed,
> Mike Folk <mfolk@xxxxxxxxxxxxx> writes:
>
> > Having seen the arguments from the HDF side and the netCDF side, I
> > still agree, wholeheartedly, with Ed. If we say HDF5 supports a
> > certain kind of compression, there should be no if's about it. It has
> > to be complete support, not 95% support.
> >
> > Mike
>
> That's funny, because Albert and Quincey have started to change my
> mind!
>
> Certainly Albert makes a good point - if zlib is built into HDF5, and
> then a user wants to link a program with zlib (say, because he wants
> to use zlib for something else), then everything will break, because
> the zlib functions will already be built into HDF5, and there will be
> clashes.
>
> (This could be solved, however, by the user just using the hdf5
> versions, and rebuilding HDF5 with a new zlib if that is required).
>
> So now I don't know what to do.
>
> I am going to cycle home and think about it. Any consensus from the
> HDF5 team on this would be very interesting.
That's us, just trying to help settle your mind on one solution. :-) :-)
> One other problem with just accepting what the user has installed is
> the version. I don't just need HDF5, I need version 1.8 or
> better. Otherwise my compile will break, because I use functions from
> the (upcoming) 1.8 release which are not in previous versions.
>
> This problem is removed if I distribute HDF5 with netCDF, because of
> course then I could distribute a HDF5 version that I know to work with
> netCDF-4.
Well, autoconf allows you to test for certain function's presence in a
dependent library, so you could use that feature to make certain that you
had a compatible HDF5 installation.
> I would like to find a way to make this easier for the end users, but
> it is not clear what the best solution is. I have posted a general
> question about this in the autoconf mailing list, to see if there is
> any community consensus there. I'll let you know if there is any
> useful feedback.
I'd certainly be interested in hearing about any good solutions.
Quincey
netcdf-hdf archives: