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
