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