Unit Testing in the netCDF-c library using cmake

It appears to be the case that all current tests in the netcdf-c source tree are integration tests. That is they only access the library using calls to the externally visible API.

The DAP4 code testing is different in that it includes (for the first time) unit tests. These tests reference code that is considered internal to the library. For the library generated under autoconf, this is not a problem because those symbols are visible in the library: nothing is hidden.

However, when using cmake and Visual Studio, the occurrence of _declspec(dllimport) and _declspec(dllexport) tags causes all symbols to be hidden except those explicitly exported via _declspec(dllexport). This declaration is hidden by the EXTERNL macro (see e.g. include/netcdf.h and netcdf_mem.h).

This means that unit tests will not work when loaded with the netcdf library using the targetlinklibrary() function in cmake.

In any case, and in order to get around this, I1. hypothesized the following options.

  1. Build two versions of the library: one for integration tests and installation and one for unit tests. One possible way to do this is to use a Visual Studio .dep file to export the otherwise hidden symbols. Frankly, I have no idea how do to this under cmake.
  2. Use the ADD_LIBRARY(X OBJECT ...) + $<TARGET_OBJECTS...> mechanism to load the individual object files containing the symbols needed for unit testing.

Neither solution is appealing.

I attempted to use the #2 approach, but it failed. It appears the the ADD_LIBRARY(... OBJECT ...) command does not operate as I expected. Perhaps someone else can figure out how to make this work.

So, for now, I have expunged the unit tests when building using cmake.


  1. The top-level CMakeLists.txt defines what I call a "shift point" where _declspec(dllimport) is used instead of _declspec(dllexport). This is defined by the command REMOVEDEFINITIONS(-DDLLEXPORT).

  2. We could suppress all internal symbols from the netcdf library generated by autoconf. We would do so by using a program like strip to only expose the exact netcdf library API and hide all other symbols. The proper time to do this would be as part of an install-hook that hid the symbols at the point when the library was being installed.

  3. Note that any .h file that includes _declspec (vid EXTERNL) must be referenced by code compiled before the shift point (see above) in the CMakeLists.txt file. But watch out that no API function in the .h file is duplicated int some other .h file in order to prevent complaints by cmake about linkage errors.

  4. EXTERNL should not be used except in include/*.h files that are intended to define an external API.

AWIPS NEXRAD Level 3 Rendered with Matplotlib

Shown here are plots for Base Reflectivity (N0Q, 94) and Base Velocity (N0U, 99) using AWIPS data rendered with Matplotlib, Cartopy, and MetPy. This example improves upon existing Level 3 Python rendering by doing the following:

  • Display scaled and labeled colorbar below each figure.
  • Plot radar radial images as coordinate maps in Cartopy and label with lat/lon.
  • 8 bit Z and V colormap and data scaling added to MetPy from operational AWIPS.
  • Level 3 data are retrieved from the Unidata EDEX Cloud server (edex-cloud.unidata.ucar.edu)
  • Raw HDF5 byte data are converted to product values.
[Read More]

New TDS Cloud Architectures: Proposal 1

The Thredds Data server (TDS) was designed to operate in a client-server architecture. Recently, Unidata has moved TDS into the cloud using its existing architecture.

There seems to be agreement inside Unidata that we need to begin rethinking that architecture to adapt to the realities of the cloud.

[Read More]

From GEMPAK to AWIPS: Building the NSHARP Dynamic Library on OS X

A little known fact in the world of AWIPS(II) is just how dependent the system still is on NAWIPS-GEMPAK. The entire National Centers Perspective is dependent on pre-built shared object files for 64-bit Linux, which means that all of the D2D plugins which extend NSHARP (for bufr obs, NPP profiles, forecast models, etc.) also depend on these libraries.

This dependency has prevented use of the NSHARP plugin in the first release (15.1.1) of the OS X CAVE client. These are the steps taken to build NSHARP and GEMPAK libraries for OS X AWIPS 16.2.2.

[Read More]

Colored Temperature Obs in CAVE D2D (NMAP2-style)

One of the new data visualizations available in the upcoming AWIPS 16.2.2 release is a recreation of the legacy GEMPAK/NAWIPS colored temperature ("color_temp") bundle.

[Read More]
Unidata Developer's Blog
A weblog about software development by Unidata developers*
Unidata Developer's Blog
A weblog about software development by Unidata developers*



News@Unidata blog

Take a poll!

What if we had an ongoing user poll in here?

Browse By Topic
Browse by Topic
« February 2017