NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
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. 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. 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. Thanks, Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdf-hdf archives: