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.
On Thu, Nov 6, 2014 at 3:06 PM, Ward Fisher <wfisher@xxxxxxxxxxxxxxxx> wrote: > Thanks all for the input re: bundling the different interfaces; it’s clear > this is more convenient. I would argue that the benefit is not strictly to > us developers at the expense of the poor users (as somebody put it :) ); > the split makes it much easier to provide support for individual > interfaces, as well as faster bug fixes as previously mentioned. > > There are significant technical hurdles to recombining the interfaces into > a single project, as it was for versions 4.1.3 and prior. There may be > avenues for making distribution more transparent and easier to keep track > of from the end user point-of-view, however. I may start a new thread once > I’ve explored a couple of ideas. > That would be great -- I've only needed to deal with C, so it's not been an issue for me, but I was thinking when reading the thread that there must be a way to simplify the building experience for end-users without bundling it all as one package/project. > Regarding the question below about binary distributions for OSX and > Windows. We provide Windows binaries because, frankly, building with Visual > Studio can be a bit of a mess, and providing the libraries packaged with > dependencies seemed like the easiest way to head off a lot of problems. > These can be downloaded here: > > - http://www.unidata.ucar.edu/software/netcdf/docs/winbin.html > > Indeed, that is a great service. Unfortunately, MS has done such a nice job of crating incompatible run-time libs, and tying the compiler version to the lib version, that libraries built with one version of the compiler can only be counted on to work correctly with executable built with the same version. So it would be helpful to provide multiple Windows binaries (yeah!). For instance, the Python provide by python.org is built with VS2008, so libraries used by extensions ideally should also be built with VS2008, and the libs Unidata is currently providing appear to be built with VS 2010. Yes, a total nightmare, this. Honestly, I'm not sure where the incompatibilities lie, so these _may_ work OK, but I'm not sure they can be relied on. One of the big issue sis file handles, and netcdf clearly needs to work with those.... > I wasn’t under the impression that there was much need for OSX binary > distributions, since OSX is essentially BSD and works with autotools and/or > CMake. I know that the popular package managers homebrew and macports > have netcdf packages (which we do not maintain), and had always thought > these must be sufficient, as nobody has said otherwise. I’d be really > interested to know if these were insufficient! > Well, I suspect that anyone building their own C or fortran code has their system set up to build, and certainly homebrew and macports do make this pretty straightforward. But if you are building binaries of your code to re-distribute, it' snot so easy... Also, folks using higher level languages that need netcdf, like Python, R, what have you, are generally not set up with a full *nix system like homebrew and macports. So pre-built binaries would be useful here. Though maybe that's the job of the wrapper maintainers, or language community. But it is really a pain to build these packages so that they can be re-distributed, I've been meaning to do it for Python for years, and haven't gotten around to it yet ;) (for python, there is now Anaconda and Enthought Canopy, that deal with this for folks, so maybe no need for Unidata to do it) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@xxxxxxxx
netcdfgroup
archives: