Further removal of HDF4 code from HDF5 code #872
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR I continue the removal of HDF4 code to it's own dispatch layer. This is all leading eventually to user-defined formats (#177), and more directly to #856, the separation of the enhanced model internal code from the HDF5 dispatch layer.
Removal of HDF4-specific Fields from _INFO_T Structs
After #856 the INFO_T structs will not contain any format-specific fields. We mostly have been discussing the (many) HDF5 fields this will impact.
But the file and variable info structs also contain some HDF4-specific fields. In this PR these have been replaced with void pointers. The pointers are used by the HDF4 dispatch layer to manage these fields. All knowledge of these fields now resides within the HDF4 dispatch code.
These same void pointers will be used to achieve the same results with the HDF5 specific fields.
HDF4 Tests
In this PR I move the HDF4 tests to new directory hdf4_test. This is straightforward - there are no dependencies on other non-HDF4 tests.
This will be necessary to enable builds with HDF4, but without HDF5. It also simplifies the already-complex build in nc_test4, and is in accordance with the dispatch layer conventions outlined in the documentation.
Reusable Dispatch Functions
There are many functions in the HDF4 dispatch table which simple return error codes (for example, all the functions that write to file return NC_EPERM, since the HDF4 dispatch layer is read-only). I have given these functions general names and moved them to the dispatch directory. (For example RO_def_var() for an nc_def_var() function for a read-only dispatch layer.)
I have used some of these functions in the libsrc4 and libsrcp directory, removing some code duplication. They can also be used in at least some cases in the dap directories, but I have not ventured that.
Documentation
I have added documentation to docs/internal.dox.
I am happy to discuss and implement any suggestions for documentation improvement or development. I will present further documentation for proposed changes for #856 this week, but this PR deals with HDF4 only.
Part of #856.
Fixes #870
Fixes #871
Fixes #869
Fixes #849