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: > Here is a summary and proposal for what should be done about netcdf4 > configrue / make with hdf5. > > I'd like to get consensus on this. > > > --- > > > Configure/build netcdf4 Issues > ------------------------------ > Robert E. McGrath > Elena Pourmal > James Laird > > Overview > ======= > > The general question is how we want the netCDF-4 source code to be > built by users. The particular technical challenge is how to link with > HDF5 in the right way. I assume we would like this to be as fool proof > and easy for users as possible. > > There are two approaches that have been proposed: > > 1) set up netcdf4 configure/make to use the 'h5cc' script > 2) set up netcdf4 configure/make to use regular compilers, with > '--with-hdf5' to point to HDF5 > > We currently have a version of #1 implemented. It is working, but > there are at least 2 irritating problems that have yet to be addressed. > We do not know how difficult it will be to fix the problems. > However, most users will not have trouble with them. > > #2 is thought to be fairly simple, but we don't have a detailed > techincal assessment. > > We have the option of staying with #1, and fixing 'h5cc' at some > point in the future, or changing to #2. > > Known Problems with H5cc > ======================= > > 1. 'h5cc' has all the warnings enabled > > This bug has been reported several times, and really should be fixed. > The fix requires modification to how the h5cc script is generated-- > probably some sed or other shell hacking. > > 2. Make in sub-directories fails in some cases > > Automake doesn't understand 'h5cc', and is not doing dependency checking > correctly. In some cases, make fails because of this. This has been > a pain for developers, but is not an issue for most users. > > There are at least possible fixes: > a) the autoconf mail list suggests fixing 'depcomp' > b) disabling dependency checking > These have not been explored in detail, and we don't know how difficult > it will be to fix this. > > We should realize that there may be other problems we don't know about. > > Not using h5cc > ============= > > The alternative to using 'h5cc' is to rewrite the netcdf-4 autoconf and > possibly other files to accept the '--with-hdf5' argument, and do > whatever > is necessary to find the right compilers, libraries, and settings. > > Ideally, this would be able to used information from, say, > libhdf5.settings, > to create the right make and link steps. > > It is not clear how much work this rewrite would be. Without trying > to do it, we can't really know if this is easier or harder to use than > 'h5cc'. Proposal > ======= > > We will to distribute netcdf-4 designed to be built with 'h5cc'. > > Essentially, keep it the way it is implemented now. > > We will address the problems with h5cc at some time in the future, but > not right now. > > 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? Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdf-hdf archives: