efdec07f3d
Replaces PR https://github.com/Unidata/netcdf-c/pull/3024 and PR https://github.com/Unidata/netcdf-c/pull/3033 re: https://github.com/Unidata/netcdf-c/issues/2753 As suggested by Ed Hartnett, This PR extends the netcdf.h API to support programmatic control over the search path used to locate plugins. I created several different APIs, but finally settled on the following API as being the simplest possible. It does have the disadvantage that it requires use of a global lock (not implemented) if used in a threaded environment. Specifically, note that modifying the plugin path must be done "atomically". That is, in a multi-threaded environment, it is important that the sequence of actions involved in setting up the plugin path must be done by a single processor or in some other way as to guarantee that two or more processors are not simultaneously accessing the plugin path get/set operations. As an example, assume there exists a mutex lock called PLUGINLOCK. Then any processor accessing the plugin paths should operate as follows: ```` lock(PLUGINLOCK); nc_plugin_path_get(...); <rebuild plugin path> nc_plugin_path_set(...); unlock(PLUGINLOCK); ```` ## Internal Architecture It is assumed here that there only needs to be a single set of plugin path directories that is shared by all filter code and is independent of any file descriptor; it is global in other words. This means, for example, that the path list for NCZarr and for HDF5 will always be the same. However internally, processing the set of plugin paths depends on the particular NC_FORMATX value (NC_FORMATX_NC_HDF5 and NC_FORMATX_NCZARR, currently). So the *nc_plugin_path_set* function, will take the paths it is given and propagate them to each of the NC_FORMATX dispatchers to store in a way that is appropriate to the given dispatcher. There is a complication with respect to the *nc_plugin_path_get* function. It is possible for users to bypass the netcdf API and modify the HDF5 plugin paths directly. This can result in an inconsistent plugin path between the value used by HDF5 and the global value used by netcdf-c. Since there is no obvious fix for this, we warn the user of this possibility and otherwise ignore it. ## Test Changes * New tests<br> a. unit_test/run_pluginpaths.sh -- was created to test this new capability.<br> b. A new test utility has been added as *unit_test/run_dfaltpluginpath.sh* to test the default plugin path list. * New test support utilities<br> a. unit_test/ncpluginpath.c -- report current state of the plugin path<br> b. unit_test/tst_pluginpaths.c -- test program to support run_pluginpaths.sh ## Documentation * A new file -- docs/pluginpath.md -- provides documentation of the new API. It includes some material taken fro filters.md. ## Other Major Changes 1. Cleanup the whole plugin path decision tree. This is described in the *docs/pluginpath.md* document and summarized in Addendum 2 below. 2. I noticed that the ncdump/testpathcvt.sh had been disabled, so fixed and re-enabled it. This necessitated some significant changes to dpathmgr.c. ## Misc. Changes 1. Add some path manipulation utilities to netcf_aux.h 2. Fix some minor bugs in netcdf_json.h 3. Convert netcdf_json.h and netcdf_proplist.h to BUILT_SOURCE. 4. Add NETCDF_ENABLE_HDF5 as synonym for USE_HDF5 5. Fix some size_t <-> int conversion warnings. 6. Encountered and fixed the Windows \r\n problem in tst_pluginpaths.c. 7. Cleanup some minor CMakeLists.txt problems. 8. Provide an implementation of echo -n since it appears to not be available on all platforms. 9. Add a property list mechanism to pass environmental information to filters. 10. Cleanup Doxyfile.in 11. Fixed a memory leak in libdap2; surprised that I did not find this earlier. ## Addendum 1: Proposed API The API makes use of a counted vector of strings representing the sequence of directories in the path. The relevant type definition is as follows. ```` typedef struct NCPluginList {size_t ndirs; char** dirs;} NCPluginList; ```` The API proposed in this PR looks like this (from netcdf-c/include/netcdf_filter.h). * ````int nc_plugin_path_ndirs(size_t* ndirsp);```` Arguments: *ndirsp* -- store the number of directories in this memory. This function returns the number of directories in the sequence if internal directories of the internal plugin path list. * ````int nc_plugin_path_get(NCPluginList* dirs);```` Arguments: *dirs* -- counted vector for storing the sequence of directies in the internal path list. This function returns the current sequence of directories from the internal plugin path list. Since this function does not modify the plugin path, it does not need to be locked; it is only when used to get the path to be modified that locking is required. If the value of *dirs.dirs* is NULL (the normal case), then memory is allocated to hold the vector of directories. Otherwise, use the memory of *dirs.dirs* to hold the vector of directories. * ````int nc_plugin_path_set(const NCPluginList* dirs);```` Arguments: *dirs* -- counted vector for providing the new sequence of directories in the internal path list. This function empties the current internal path sequence and replaces it with the sequence of directories argument. Using an *ndirs* argument of 0 will clear the set of plugin paths. ## Addendum 2: Build-Time and Run-Time Constants. ### Build-Time Constants <table style="border:2px solid black;border-collapse:collapse"> <tr style="outline: thin solid;" align="center"><td colspan="4">Table showing the build-time computation of NETCDF_PLUGIN_INSTALL_DIR and NETCDF_PLUGIN_SEARCH_PATH.</td> <tr style="outline: thin solid" ><th>--with-plugin-dir<th>--prefix<th>NETCDF_PLUGIN_INSTALL_DIR<th>NETCDF_PLUGIN_SEARCH_PATH <tr style="outline: thin solid" ><td>undefined<td>undefined<td>undefined<td>PLATFORMDEFALT <tr style="outline: thin solid" ><td>undefined<td><abspath-prefix><td><abspath-prefix>/hdf5/lib/plugin<td><abspath-prefix>/hdf5/lib/plugin<SEP>PLATFORMDEFALT <tr style="outline: thin solid" ><td><abspath-plugins><td>N.A.<td><abspath-plugins><td><abspath-plugins><SEP>PLATFORMDEFALT </table> <table style="border:2px solid black;border-collapse:collapse"> <tr style="outline: thin solid" align="center"><td colspan="2">Table showing the computation of the initial global plugin path</td> <tr style="outline: thin solid"><th>HDF5_PLUGIN_PATH<th>Initial global plugin path <tr style="outline: thin solid"><td>undefined<td>NETCDF_PLUGIN_SEARCH_PATH <tr style="outline: thin solid"><td><path1;...pathn><td><path1;...pathn> </table> |
||
|---|---|---|
| .github | ||
| cmake | ||
| conda.recipe | ||
| ctest_scripts | ||
| dap4_test | ||
| docs | ||
| examples | ||
| fuzz | ||
| h5_test | ||
| hdf4_test | ||
| include | ||
| libdap2 | ||
| libdap4 | ||
| libdispatch | ||
| libhdf4 | ||
| libhdf5 | ||
| liblib | ||
| libncpoco | ||
| libncxml | ||
| libnczarr | ||
| libsrc | ||
| libsrc4 | ||
| libsrcp | ||
| nc_perf | ||
| nc_test | ||
| nc_test4 | ||
| ncdap_test | ||
| ncdump | ||
| ncgen | ||
| ncgen3 | ||
| nctest | ||
| nczarr_test | ||
| NUG | ||
| oc2 | ||
| plugins | ||
| unit_test | ||
| .clang-tidy | ||
| .gitignore | ||
| acinclude.m4 | ||
| bootstrap | ||
| CITATION.cff | ||
| cmake_uninstall.cmake.in | ||
| CMakeInstallation.cmake | ||
| CMakeLists.txt | ||
| COMPILE.cmake.txt | ||
| config.h.cmake.in | ||
| config.h.cmake.in.old-works | ||
| configure.ac | ||
| COPYRIGHT | ||
| CTestConfig.cmake.in | ||
| CTestCustom.cmake.in | ||
| dods.m4 | ||
| FixBundle.cmake.in | ||
| INSTALL.md | ||
| lib_flags.am | ||
| libnetcdf.settings.in | ||
| Makefile.am | ||
| mclean | ||
| nc-config.cmake.in | ||
| nc-config.in | ||
| netcdf.pc.in | ||
| netCDFConfig.cmake.in | ||
| PostInstall.cmake | ||
| README.md | ||
| RELEASE_NOTES.md | ||
| s3cleanup.in | ||
| s3gc.in | ||
| test_common.in | ||
| test_prog.c | ||
| test-driver-verbose | ||
| wjna | ||
Unidata NetCDF
About
The Unidata network Common Data Form (netCDF) is an interface for scientific data access and a freely-distributed software library that provides an implementation of the interface. The netCDF library also defines a machine-independent format for representing scientific data. Together, the interface, library, and format support the creation, access, and sharing of scientific data. The current netCDF software provides C interfaces for applications and data. Separate software distributions available from Unidata provide Java, Fortran, Python, and C++ interfaces. They have been tested on various common platforms.
Properties
NetCDF files are self-describing, network-transparent, directly
accessible, and extendible. Self-describing means that a netCDF file
includes information about the data it contains. Network-transparent
means that a netCDF file is represented in a form that can be accessed
by computers with different ways of storing integers, characters, and
floating-point numbers. Direct-access means that a small subset of a
large dataset may be accessed efficiently, without first reading through
all the preceding data. Extendible means that data can be appended to
a netCDF dataset without copying it or redefining its structure.
Use
NetCDF is useful for supporting access to diverse kinds of scientific data in heterogeneous networking environments and for writing application software that does not depend on application-specific formats. For information about a variety of analysis and display packages that have been developed to analyze and display data in netCDF form, see
More information
For more information about netCDF, see
Latest releases
You can obtain a copy of the latest released version of netCDF software for various languages:
Copyright
Copyright and licensing information can be found here, as well as in the COPYRIGHT file accompanying the software
Installation
To install the netCDF-C software, please see the file INSTALL in the netCDF-C distribution, or the (usually more up-to-date) document:
- Building NetCDF with CMake
- Building NetCDF with Autoconf/Automake/Libtool
- Building or Getting Binaries for NetCDF on Windows
Documentation
A language-independent User's Guide for netCDF, and some other language-specific user-level documents are available from:
- Language-independent User's Guide
- NetCDF-C Tutorial
- Fortran-90 User's Guide
- Fortran-77 User's Guide
- netCDF-Java/Common Data Model library
- netCDF4-python
A mailing list, netcdfgroup@unidata.ucar.edu, exists for discussion of the netCDF interface and announcements about netCDF bugs, fixes, and enhancements. For information about how to subscribe, see the URL
Feedback
We appreciate feedback from users of this package. Please send comments, suggestions, and bug reports to support-netcdf@unidata.ucar.edu.