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)
