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.
Hi Ward Thank you for your explanations. I can understand the advantages of this approach from the NetCDF code developers point of view, for whom bug-fixing, adding new features like F2003, etc, are of paramount importance. That is not the universe of regular NetCDF users, though. The new approach also seems to have sacrificed an important benefit for the final user, which should also count for Unidata/NetCDF. Having a single release (call it monolithic if you want) for all bindings (C,Fortran, maybe C++, more exotic languages also?) bundled in a consistent package, was very convenient and very helpful, and this seems to be gone since 4.1.3. I have read many messages (and answered some) in this list from people (myself included) having trouble building the various recent bindings. It is harder to do it now than it was before, when the bindings were bundled together, and a single configure/make/make_install would take care of everything. I wonder if along with the Git-based code development, Unidata/NetCDF-group could restore the *external* code release in the original bundling/style, and with the same building tools, for the benefit of the final users. Thank you, Gus Correa PS - Yes, I do understand the initial thread was about NetCDF3 vs NetCDF4, which is a separate discussion in itself. I don't want to derail that discussion either. However, the equally general issue of language bindings was brought up by somebody else, and I believe it is relevant. My apologies if other people think it is not. On 11/06/2014 03:26 PM, Ward Fisher wrote:
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 <mailto: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> <mailto: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 <tel:%28206%29%20526-6959> voice 7600 Sand Point Way NE (206) 526-6329 <tel:%28206%29%20526-6329> fax Seattle, WA 98115 (206) 526-6317 <tel:%28206%29%20526-6317> main reception Chris.Barker@xxxxxxxx <mailto:Chris.Barker@xxxxxxxx> <mailto:Chris.Barker@xxxxxxxx <mailto:Chris.Barker@xxxxxxxx>> _________________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx <mailto:netcdfgroup@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/__mailing_lists/ <http://www.unidata.ucar.edu/mailing_lists/> _________________________________________________ netcdfgroup mailing list netcdfgroup@xxxxxxxxxxxxxxxx <mailto:netcdfgroup@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/__mailing_lists/ <http://www.unidata.ucar.edu/mailing_lists/>
netcdfgroup archives: