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.
I do have to agree with Gus: Having all bindings in one release makes my life a lot easier when I have to integrate a new release of the code. Since we do try to follow the releases pretty closely, it means I've got to spend more time looking to make sure the Fortran and C bindings are the latest and are compatible. And, since I also have to help others around the University, I often have to ansewr these questions a number of times. I get pretty confident I know which releases of what code are where we want to be after awhile. I can understand the benefits from the developer side, but us poor end-users need to be remembered, too. gerry On Thu, Nov 6, 2014 at 2:57 PM, Gus Correa <gus@xxxxxxxxxxxxxxxxx> wrote: > 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 mailing list > netcdfgroup@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > -- Gerry Creager NSSL/CIMMS 405.325.6371 ++++++++++++++++++++++ “Big whorls have little whorls, That feed on their velocity; And little whorls have lesser whorls, And so on to viscosity.” Lewis Fry Richardson (1881-1953)
netcdfgroup archives: