BLD: Get CMake build compiling on Cygwin.

Mostly changing to Markdown files to a format Doxygen recognizes.

CMakeLists.txt

@@ -215,7 +215,7 @@ FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/CTestCustom.cmake DESTINATION ${CMAKE_CURR
 
 # Set Memory test program for non-MSVC based builds.
 # Assume valgrind for now.
-IF((NOT MSVC) AND (NOT MINGW))
+IF((NOT MSVC) AND (NOT MINGW) AND (NOT ISCYGWIN))
   SET(CTEST_MEMORYCHECK_COMMAND valgrind CACHE STRING "")
 ENDIF()
 

RELEASE_NOTES.md

@@ -277,11 +277,13 @@ See [GitHub #1251](https://github.com/Unidata/netcdf-c/issues/1251).
 ### 4.5.0-rc1 - June 5, 2017
 
 * [Enhancement] DAP4 is now included. Since dap2 is the default for urls, dap4 must be specified by
-(1) using "dap4:" as the url protocol, or
-(2) appending "#protocol=dap4" to the end of the url, or
-(3) appending "#dap4" to the end of the url
-Note that dap4 is enabled by default but remote-testing is
-disabled until the testserver situation is resolved.
+    1. using "dap4:" as the url protocol, or
+    2. appending "\#protocol=dap4" to the end of the url, or
+    3. appending "\#dap4" to the end of the url
+
+    Note that dap4 is enabled by default but remote-testing is
+    disabled until the testserver situation is resolved.
+
 * [Enhancement] The remote testing server can now be specified with the `--with-testserver` option to ./configure.
 * [Enhancement] Modified netCDF4 to use ASCII for NC_CHAR.  See [Github Pull request #316](https://github.com/Unidata/netcdf-c/pull/316) for more information.
 * [Bug Fix] Corrected an error with how dimsizes might be read. See [Github #410](https://github.com/unidata/netcdf-c/issues/410) for more information.

docs/filters.md

@@ -438,7 +438,7 @@ This means that some mechanism is needed to translate between the HDF5 id+parame
 3. It must be possible to modify the set of visible parameters in response to environment information such as the type of the associated variable; this is required to mimic the corresponding HDF5 capability.
 4. It must be possible to use filters even if HDF5 support is disabled.
 
-Note that the term "visible parameters" is used here to refer to the parameters provided by "nc_def_var_filter" or those stored in the dataset's metadata as provided by the JSON codec. The term "working parameters" refers to the parameters given to the compressor itself and derived from the visible parameters.
+Note that the term "visible parameters" is used here to refer to the parameters provided by `nc_def_var_filter` or those stored in the dataset's metadata as provided by the JSON codec. The term "working parameters" refers to the parameters given to the compressor itself and derived from the visible parameters.
 
 The standard authority for defining Zarr filters is the list supported by the NumCodecs project [7].
 Comparing the set of standard filters (aka codecs) defined by NumCodecs to the set of standard filters defined by HDF5 [3], it can be seen that the two sets overlap, but each has filters not defined by the other.
@@ -514,8 +514,8 @@ This interrogation operates by seeing if certain well-known (function) names are
 
 There will be two library types:
 
-1. HDF5 — exports a specific API: "H5Z_plugin_type" and "H5Z_get_plugin_info".
-2. Codec — exports a specific API: "NCZ_get_codec_info"
+1. HDF5 — exports a specific API: `H5Z_plugin_type` and `H5Z_get_plugin_info`.
+2. Codec — exports a specific API: `NCZ_get_codec_info`
 
 Note that a given library can export either or both of these APIs.
 This means that we can have three types of libraries:
@@ -605,7 +605,7 @@ is stored in the JSON dictionary form described earlier.
 
 The Codec style, using JSON, has the ability to provide very complex parameters that may be hard to encode as a vector of unsigned integers.
 It might be desirable to consider exporting a JSON-base API out of the netcdf-c API to support user access to this complexity.
-This would mean providing some alternate version of "nc_def_var_filter" that takes a string-valued argument instead of a vector of unsigned ints.
+This would mean providing some alternate version of `nc_def_var_filter` that takes a string-valued argument instead of a vector of unsigned ints.
 This extension is unlikely to be implemented until a compelling use-case is encountered. 
 
 One bad side-effect of this is that we then may have two classes of plugins.
@@ -812,7 +812,7 @@ The h5 tag indicates that they assume that the result of the parse is a set of u
   * idp will contain the first constant — the filter id
   * nparamsp will contain the number of params 
   * paramsp will contain a vector of params — the caller must free
-This function can parse single filter spec strings as defined in the section on \ref filters_syntax.
+This function can parse single filter spec strings as defined in the section on [Filter Specification Syntax](#filters_syntax).
 2. *int ncaux\_h5filterspec\_parselist(const char* txt, int* formatp, size\_t* nspecsp, struct NC\_H5\_Filterspec*** vectorp);*
   * txt contains the text of a sequence '|' separated filter specs.
   * formatp currently always returns 0.
@@ -852,7 +852,7 @@ The include file *netcdf\_meta.h* contains the following definition.
 ````
     #define NC_HAS_MULTIFILTERS   1
 ````
-This, in conjunction with the error code *NC\_ENOFILTER* in *netcdf.h* can be used to see what filter mechanism is in place as described in the section on \ref filters_compatibility.
+This, in conjunction with the error code *NC\_ENOFILTER* in *netcdf.h* can be used to see what filter mechanism is in place as described in the section on [incompatibities](#filters_compatibility).
 
 1. !defined(NC\_ENOFILTER) && !defined(NC\_HAS\_MULTIFILTERS) — indicates that the old pre-4.7.4 mechanism is in place.
     It does not support multiple filters.