NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
"Robert E. McGrath" <mcgrath@xxxxxxxxxxxxx> writes: > O >> Well, I was thinking this whole thing through, and came up with a >> third option. It's a little dramatic, but it might be the best idea... >> We could create a netcdf directory under the hdf5 directory, and >> store >> all our netcdf code in your repository. Then we modify the HDF5 >> configure so that, with an --enable-netcdf option, it will build >> netcdf as part of HDF5. >> This has the following advantages: >> 1 - User only has to download one tarball. >> 2 - User only has to go through one configure/make process. >> 3 - Guaranteed to build netCDF with same compiler as HDF5. >> 4 - User only has to link to one library instead of two. >> This would also solve the h5cc problem, since I assume you don't use >> that in your own build, because you know at build time where all the >> HDF5 libraries and headers are. >> We could do this and still keep the main control of the code in >> Unidata's CVS server, using the CVS vendor feature to import it into >> the NCSA CVS server. >> Any thoughts? >> > > This would be a bit of work to get it right. We'd have to add options > to build HDF with and without netcdf4. If you want options to build > netCDF3 only, we'd have to deal with that. If there are netcdf-4 > specific > options, we'd have to deal with that. > > All do-able, but not explored yet. > > The one big advantage of the current approach is that you can build > netCDF4 using a binary installation of HDF5. This is not only less > work, it lets people build netCDF on a system where HDF is installed > by the sysadmins, using the same HDF as everybody on the system. > > Another advantage of the combined CVS tree would be that it would be > easier > to include netcdf4 in our auto testing, it would just happen. > > > This seems like a good idea for the final product. Do we want to > tackle this now? Would it be better to wait until we're ready for > production? > > > I don't think we will even try this until after netCDF-4.0 is released. As I recall, the idea was to come up the the long-term distribution plan. If I can summarize discussion so far, I would say the plan is: * Initial release of netCDF-4 and HDF 1.8 will occur this Summer. Users will install them one at a time, Unidata and NCSA will distribute netCDF and HDF5 as we do today. NetCDF-4 will insure that a correct version of HDF5 is installed. Users will have to link to both netCDF and HDF5 libraries. * About six months after initial release, some combined installations will be available. Users will be able to download one tarball from the Unidata site, and install both netCDF and HDF-5 libraries. They will still have to link to both libraries. * Within a year of initial release, a cvs merge of code bases will allow users to create a single library, with a single download and install procedure. NetCDF-4 will be a optionally enabled part of the regular HDF5 distributions. Users will only need to link to one library, the HDF5 one. * Additionally, a netCDF-only release will be available from Unidata. It will allow us to distribute betas and other updates, and allow users to install independently from HDF5 installation. Users may build HDF5 without netCDF, then build netCDF, then link to both libraries. Only enthusiastic beta testers and users in dire need of the latest release will attempt this. * As netCDF beta code becomes release code, it will be merged into HDF5 releases. Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdf-hdf archives: