Good afternoon,
On 1/24/13 3:55 PM, Pedro Vicente wrote:
Ward
CMake support also provides for Visual-Studio based netCDF-C
builds. The development/integration environment is Windows 7
(64-bit) with Visual Studio 10
Good to know.
Some time ago I built a special Visual Studio 10 made netCDF 4.2.0,
available here
http://nco.sourceforge.net/nco_qt_msvc.shtml
The goal was to support a "native" Windows NCO build.
One thing that I wanted to avoid was to build Visual Studio projects
by "hand", so I ended up using this framework called "Qt", that
automatically generates
a Visual Studio project from a Qt project, a simple text format with
the list of files , similar to Makefile.am from GNU autoconfig, that I
think is the same idea used by CMake.
Qt is a terrific toolkit/framework; I've been using it for quite a while
and am encouraged by what looks to be easy integration between CMake and
QMake based projects. While the syntax is a bit different, you are
absolutely correct that the <project>.pro files Qt uses are similar to
the CMake and autotools-based config files. Incidentally, my response
yesterday could be construed to mean that we had dropped our
conventional autotools-based build support. For the foreseeable future,
we are maintaining both in parallel.
I had to do some minor changes to the library source code in order to
build with Visual Studio 10.
I ended up porting mostly everything (libraries, tests, tools) with
the exception of ncgen (some compiler error related to the generation
of a NAN, I think)
I will be happy to share what I did with the netCDF team, if you are
interested.
Thank you; I believe your project was one of several used during the
initial 'how does CMake work/what is the syntax?' review at the start of
the CMake integration project, in terms of structure and layout. These
references were very informative, and helped me get up to speed on CMake
much quicker than would otherwise have been possible.
But, it seems that, with this new release , everything will just
compile with Visual Studio 10 ? Meaning no source code changes ?
This is correct; there will be a couple of caveats included in the
documentation, but for the most part everything will just compile with
Visual Studio 10. This includes the netCDF-C utilities as well as the
libraries, and full netCDF4 and DAP support.
The two exceptions, as I recall, are the following:
1. Run-time warnings related to cross-dll memory management between the
netcdf and hdf5 libraries, and how to safely ignore them.
2. Large File Support (64-bit offset) on 32-bit Windows builds.
The solutions to both of these problems can be implemented, but the
engineering involved would delay the 4.3 release longer than necessary,
especially since both issues can be worked around pretty easily in the
interim. Specific details will be provided when I've completed the
release documentation, but working around these issues does not involve
code changes for any projects that depend upon netcdf.
Will this build include the other libraries generally used by netCDF
applications?
1) UDunits2
2) OpenDap
OpenDap, yes. UDunits2 is a bit trickier. On Non-Windows systems, or
on Windows systems with a posix/posix-like environment such as cygwin,
the netCDF libraries will work with UDunits2. For Visual Studio based
builds, it doesn't appear that there exists a compatible UDunits2 library.
I see that OpenDap (OC 2) is included in the netcdf-4.2.1.1 distro,
but not UDunits2.
There have been requests to have these libs as "native" compiled in
Windows, and I have been trying to port them to Visual Studio 10, but
if this would be available from Unidata, that would be fantastic !
The decision to provide these libraries independent of a binary
installer is something I'll need to discuss with the rest of the netCDF
and Unidata tech team. Whether we do or not is not a foregone
conclusion, but at the very least I should be able to provide directions
for building the 64-bit libcurl libraries for DAP support, and download
links for the 32-bit libcurl and 32/64 bit HDF5 libraries (including the
dependent zlib windows libraries).
Have a great afternoon,
-Ward
Pedro
------
Pedro Vicente, Earth System Science
University of California, Irvine
http://www.ess.uci.edu/
----- Original Message ----- From: "Ward Fisher"
<wfisher@xxxxxxxxxxxxxxxx>
To: <netcdfgroup@xxxxxxxxxxxxxxxx>
Sent: Thursday, January 24, 2013 1:53 PM
Subject: Re: [netcdfgroup] CMake success
Good afternoon,
Our first official netCDF-C release with CMake integration will be
version 4.3. There isn't an official release date set yet, but it
should be soon. In addition to easier packaging, CMake support also
provides for Visual-Studio based netCDF-C builds. The
development/integration environment is Windows 7 (64-bit) with Visual
Studio 10, and supports both 32 and 64-bit based builds.
Have a great afternoon!
-Ward
On 1/24/13 1:40 PM, Nico Schlömer wrote:
Hi all,
I just played around with netCDF from the developers' branch and was
very pleased to find CMake integrated. Now,packaging netCDF is *so*
much simpler. For example, I just created a Debian package for dev in
no time. Thanks for adopting this!
I'm now curious to know if there are plans to release netCDF with this
functionality anytime soon. This would help me decide whether I'd be
worthwhile fixing the package for the pre-CMake package or not.
Cheers,
Nico
_______________________________________________
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/
