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.
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 Fri, May 30, 2014 at 10:58 AM, Chris Barker <chris.barker@xxxxxxxx> wrote: > > Not really addressing the key point, but... > > On Fri, May 30, 2014 at 9:39 AM, David W. Pierce <dpierce@xxxxxxxx> wrote: > > >> The maintenance of the R package that supplies a netcdf interface is >> something that I have considered as well. I first released it over 10 years >> ago and at some point it will likely not be possible for me to continue >> sole-sourcing it. One of the biggest issues is support for Windows and the >> Mac. Since I don't use R on WIndows and have no access to a Mac it's always >> a struggle to keep the package working on those platforms. Please correct >> me if I'm wrong, but the netcdf folks support binaries for Windows but not >> in the format needed for R applications, which is mingw. So there is the >> burden of creating Windows netcdf library binaries as well. >> > > We will support NetCDF in MinGW as far as we can; it is certainly possible to compile with mingw, although there are tricks to making it work on Windows. > in generally, mingw is quite compatible with stuff compiled by MSVS -- how > could it call system dlls, after all? So I suspect that the unidata-built > dll would work fine. > > Unfortunately, my experience makes me think it probably won't, although I would love to be proven wrong on this. When bringing libnetcdf to Windows, I found MinGW/MSVC interoperability to be brittle. Our first attempt, cross-compiling libnetcdf for use with Visual Studio using an MSYS/MinGW environment worked, but not in a stable manner. This is because MinGW uses an older MSVCRT which is not completely compatible with the runtime shipped with newer editions of Visual Studio. Ultimately, we discarded the cross-compiling solution and instead adopted CMake, which made generating VS-native builds much easier. NetCDF should build in MinGW; CMake supports different Makefile targets suitable for use with MinGW. You can also use the autotools generated build tools. The main issue I've run in to is configuring a 64-bit MinGW toolchain which will build a 64-bit libnetcdf for use with R or any other MinGW-dependent program. It can be done; I just need to find the time to really nail it down. > But you still need someone on Windows testing, debugging, etc... I'm not > an R user, but for Python, packages are built by folks that do Windows > packaging for Python -- is there anything like that for R? > > >> In the end, if the wider netcdf community was interested of the idea of >> transitioning ncdf4 (and my other netcdf package, ncview, as well I >> suppose) to a more Unidata or community supported model, as Roy may be >> hinting, I certainly would be all for that. >> > > Well, community supported is tricky to "just do" you can provide fertile > ground, but something still has to grow. > > But a good first step is to put the code up on gitHub -- that way users > can quickly grab a copy, test a pre-release version, maybe try a bug-fix, > report issues, etc. If you make it easy for folks to help, they may just do > it... > > I agree; our recent move to github has resulted in a number of bug fixes and other contributions to netcdf; the trick was making it easy to do, which github certainly does. -Ward > You could probably put it on the unidata organization project, but it > doesn't much matter, really. > > -CHB > > > > > -- > > 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 mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ >
netcdfgroup archives: