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.
Hello all, I just wanted to jump in regarding the split after 4.1.3. On Thu, Nov 6, 2014 at 1:07 PM, Gus Correa <gus@xxxxxxxxxxxxxxxxx> wrote: On 11/06/2014 02:06 PM, Chris Barker wrote: > >> On Thu, Nov 6, 2014 at 10:59 AM, Nick Papior Andersen >> <nickpapior@xxxxxxxxx <mailto:nickpapior@xxxxxxxxx>> wrote: >> >> (…) The original idea behind splitting the libraries, as I understand it, was to make it easier to release updates and bug fixes without having to release a new version of every interface. This way, a critical bug fix in netcdf-c would not have to wait for a bug fix in netcdf-fortran, or vice versa. This style of distributing the libraries is more cumbersome if you continue to look at netcdf as a monolithic set of interfaces, but if you consider it to be a set of independent interfaces, it makes a lot more sense. The actual *releases* from 4.3.0 onward on github contain the configure script and other autotools-generated files. The code in the development branch does not, as there isn’t much need to track changes made to these files. They can be generated on the fly with autoreconf -if as needed by anybody working with unstable development code. Which you are of course welcome to do. CMake integration is also in place for the C and Fortran interfaces; it is still pending (I believe) for the C++ interface, but will be included there as well. One of the strengths of CMake is the fact that it is so much more cross-platform capable than autotools, which is why it’s seeing such strong adoption rates amongst software developers. We’re using CMake to allow for easier compilation on Windows in an MSVC environment, and are not planning on abandoning autotools in the near future :). Another benefit of adopting CMake is that it has let us move away from cron jobs and perl scripts to a more formal, modern Continuous Integration testing environment, CDash. The netcdf public CDash dashboards may be found here: - http://my.cdash.org/index.php?project=netcdf-c - http://my.cdash.org/index.php?project=netcdf-fortran Coupled with tools like Virtualbox and Vagrant, this has made our cross-platform testing environment *very* portable and *very* extendable. As an example of this, it took me about 20 minutes total, earlier this week, to add 32/64-bit versions of the latest fedora and ubuntu linux distributions to our testbed. I don’t mean to derail the conversation, but I did want to make sure folks knew that the autotools scripts are still in place for our releases through github, or those releases downloaded from our ftp site. I would be very hesitant to make such a broad change without any sort of warning :). -Ward Nevertheless, after about NetcCDF version 4.1.3, > the three main bindings (C, Fortran, C++) were separated, > and no longer distributed from a single tarball. > They don't seem to have the same building framework with > Gnu Autotools either. > There is some stuff on Git, but not nearly as easy to handle > as it used to be. > The release numbers are now different (inconsistent?) > across these three bindings also. > Using CMake perhaps, instead of Gnu AutoTools also? > > Maybe there is a rationale for that, but I don't quite understand why. > > Anyway, this made it harder to build, keep, and use a consistent > and up-to-date group of bindings in Linux machines, > and also made it harder to cater for Fortran users/programmers. > Even Linux distribution packages lagged behind. > > That is something that I think Unidata and the NetCDF group > could/should look into with more interest, > and hopefully return to the good old days of a single > and comprehensive tarball with C, Fortran, and C++ bindings, > plus an easy to use "configure;make;make install" setup. > This may not cover Windows and Macs, but will be help a lot the > Linux users. > > My two cents of biased opinion. > > Thank you, > Gus Correa > Lamont-Doherty Earth Observatory of Columbia University > > > In this regard, I wish > > >> -- >> >> 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 <mailto:Chris.Barker@xxxxxxxx> >> >> >> _______________________________________________ >> netcdfgroup mailing list >> netcdfgroup@xxxxxxxxxxxxxxxx >> For list information or to unsubscribe, visit: >> http://www.unidata.ucar.edu/mailing_lists/ >> >> > _______________________________________________ > netcdfgroup mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ >
netcdfgroup archives: