bugfix: CMake < 3.20 HDF5 build, Intel compiler performance

• fixed self-build of HDF5 with CMake < 3.20. CMake >= 3.20 still recommended to improve performance of HDF5/ZLIB autobuild.
• now works with Intel oneAPI LLVM NextGen compiler ("icx" "ifx" instead of "icc" "ifort"). As before, continues to work with Intel oneAPI Classic.
• Intel compiler: use "-xHost" for improved runtime speed
• zlib updated from 2.0.4 => 2.0.5
• don't override CMAKE_INSTALL_PREFIX to avoid problems when h5fortran used via CMake FetchContent
• read_scalar: use TKR-distinct procedures instead of select type to improve runtime performance and overall reliability. Likely to do the same for 1d..7d reads in the future.

Find{HDF5,SZIP} improvements, build scripts enhanced

• improve HDF5 build (when needed)
• improve FindHDF5: finds parallel component if requested, more robust across platforms, especially CentOS
• improve FindSZIP: work better with libaec, the SZIP replacement with BSD license

%open, %close for files, %open_group, %close_group for groups

%open, %close for files--the older %initialize, %finalize continue to work.
%open_group, %close_group for groups now.

Added a destructor finalization method that automatically flushes data to disk and closes file when leaving procedure scope. This helps avoid data corruption if user forgets to %close().

updated to zlib 2.0.4

correct error message when compilers ABI-compatible

v3.8.1

correct ABI check error message

TKR-interface instead of select type

refactored h5fortran v3.8.0 internal polymorphism to use TKR-unique interfaces instead of select type. That is, compile-time polymorphism instead of runtime polymorphism. This helps give clearer compile-time warnings/errors, improved runtime stability, specifically for GCC 11.1 which has a always crashing on file write bug that this fixes.

zlib 2.0.3 patch to support GCC MPICC

use patched zlib 2.0.3 that also works with GCC MPICC (was a bugfix).
This should remove anyone's need for -Dzlib_legacy

add option "cmake -Dzlib_legacy" for Zlib 1.x fallback

In case of a regression with Zlib 2.x on some less common computers, we provide a workaround to use Zlib 1.x by

cmake -B build -Dzlib_legacy=on

Please let us know and/or report the issue to zlib-ng project as Zlib 2.x should be a drop-in replacement for Zlib 1.x.

allow system zlib when building hdf5

allow system zlib to be used when building hdf5

this avoids twice-defined ZLIB::ZLIB errors

If there's still errors, recommend manually specifying to build HDF5:

cmake -B build -Dhdf5_external=on

zlib-ng for self-build

Whether manual or auto build HDF5 library, we now use zlib-ng 2.0.2 stable release. They claim considerably faster read and write. Also zlib-ng has extensive testing beyond legacy zlib.

better install location default

v3.6.9

v3.6.9