The HDF5 include directory needs to be updated when explicitly setting the HDF5 libraries and include path. This is done on line 561 when FindPackage finds the hdf5 libraries, but was not being done in the manual setting.
A couple of the `has_XX` variables seem to have values of OFF or ON instead of `empty` or ON which causes incorrect output from the nc-config script since it is using `-z` to test whether the variable is non-empty. This causes nc-config to incorrectly report that the library supports HDF5 or has the version 2 api.
Required PNetCDF version is 1.6.1 or greater; not 1.6.0 as I previously thought.
Note that this is pull request may (partially) satisfy Issue #194 which I just found.
If the netcdf cmake build is configured with explicitly specified hdf5 c and hl libraries:
```
-DHDF5_C_LIBRARY:PATH=${ACCESS}/lib/libhdf5.dylib \
-DHDF5_HL_LIBRARY:PATH=${ACCESS}/lib/libhdf5_hl.dylib \
-DHDF5_INCLUDE_DIR:PATH=${ACCESS}/include \
```
Then it looks like the HDF5_C_LIBRARIES and HDF5_HL_LIBRARIES variables do not get set and then this causes the HDF5 libraries to be omitted from the `TLL_LIBS` symbol in liblib/CMakeLists.txt. This is subsequently used to build `ALL_TLL_LIBS` which is used for `LIBS` which is output as the `Extra libraries: @LIBS@` in libnetcdf.settings.in
The output for `-- Linking against:` is also incorrect as it omits the hdf5 libraries: Output without suggested change:
```
-- Linking against: /usr/lib/libdl.dylib;/usr/lib/libm.dylib;/opt/local/lib/libz.dylib;/opt/local/lib/libcurl.dylib
(later in file)
Extra libraries: -ldl -lm -lz -lcurl
```
versus output with suggested change:
```
-- Linking against: /Users/gdsjaar/src/seacas-parallel/lib/libhdf5_hl.dylib;/Users/gdsjaar/src/seacas-parallel/lib/libhdf5.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib;/opt/local/lib/libz.dylib;/opt/local/lib/libcurl.dylib
(later in file)
Extra libraries: -lhdf5_hl -lhdf5 -ldl -lm -lz -lcurl
```
This also causes a link failure when building libnetcdf.dylib
Re e-eupport VGQ-678069
It was noticed that an attribute value of "nan." was being treated as
legal (it should be "nan"). The reason is that sscanf was not be checked
to see that all the attribute value characters were being read.
Solution is to verify that all characters were being consumed.
Re e-eupport VGQ-678069
It was noticed that an attribute value of "nan." was being treated as
legal (it should be "nan"). The reason is that sscanf was not be checked
to see that all the attribute value characters were being read.
Solution is to verify that all characters were being consumed.
Re e-eupport VGQ-678069
It was noticed that an attribute value of "nan." was being treated as
legal (it should be "nan"). The reason is that sscanf was not be checked
to see that all the attribute value characters were being read.
Solution is to verify that all characters were being consumed.
