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/
>
