Optimize Doxygen build process by skipping rebuilds when input files are unchanged, using timestamp checks in CMake configuration.
Behavior:
Skip Doxygen build if input files unchanged using timestamp check in CMakeLists.txt, hl/src/CMakeLists.txt, and src/CMakeLists.txt.
Introduces stamp files (hdf5lib_doc.stamp, hdf5hllib_doc.stamp) to track changes.
Documentation:
add_custom_command and add_custom_target used to manage Doxygen builds.
Shared Doxygen content inputs defined in top-level CMakeLists.txt for reuse.
Misc:
Reorder add_subdirectory(src) in CMakeLists.txt for visibility of Doxygen variables.
Provided a link back to The HDF Group's consulting and contact us pages, added a link for the forum post reference, and added U.S. in the NSF acknowledgement text.
* Update release progress badges to use Priority-based categorization
- Replace "Release Blockers"/"Release Must Do" with "Critical Priority"/"High Priority"
- Switch issue filtering from Release gating field to Priority field (P0 - Critical/P1 - High)
- Remove "Nice to Have" badge from workflow and README
- Add failure step: on workflow error, update both badge gist files to bright
purple (BF00FF) with "FAILURE" message
- Version auto-detected from src/H5public.h for milestone filtering
* Fix stale class docstring: release blocker -> priority issue
Intel's icx compiler defines _WIN32 (with underscore) but not WIN32,
causing unistd.h and other POSIX headers to be incorrectly included
on Windows builds.
Closes can_apply and set_local filter callbacks skipped for H5T_VARIABLE dtypes #5942. A more detailed explanation of the rationale for this PR is in the linked issue.
Mandatory filters can be now applied to variable-length data. This notably includes h5py object strings and NpyStrings.
Optional filters applied to variable-length data no longer skip can_apply and set_local, only to jump directly to filter. This fixes hdf5_blosc and HDF5_Blosc2, which rely on set_local. Note that all filters which have neither can_apply nor set_local have always worked fine with vlen data, as long as they were tagged as optional. Notable examples are deflate, lzf, bzip2 (from hdf5plugin), and lz4 (also from hdf5plugin).
Lossy filters, such as scale-offset, are and remain untested and most likely broken, as I expect them to treat the vlen metadata as numbers and corrupt it. The right place to ensure proper behaviour is their can_apply function, which however is broken (filters: can_apply does nothing for optional filters #6161).
Build-tree exports can't diverge from install-tree exports — the export(EXPORT ...) reads directly from the install export sets. No manual list to keep in sync.
Removed 3 global variables (HDF5_STATIC_LIBRARIES_TO_EXPORT, HDF5_JAVA_LIBRARIES_TO_EXPORT, HDF5_UTILS_TO_EXPORT) and their ~21 set_global_variable calls across tool/utility files.
Fixed the static-only build bug in the PR where the base export set was guarded by BUILD_SHARED_LIBS, breaking tools export.
Removed redundant utils in export files — the PR was dumping tools into all three build-tree export files (java, static, shared). Now they correctly appear only in the base export.
Ensure that the Subfiling VFD's stub file gets truncated when subfiles are
being truncated to avoid a potentially unreadable file when the EOF doesn't
match the stored EOF value
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
Removes the force-setting of ZLIB_USE_EXTERNAL and SZIP_USE_EXTERNAL to
ON when HDF5_ALLOW_EXTERNAL_SUPPORT is GIT or TGZ so that zlib and
szip can be independently built from the system or externally as desired
Refactor the cross-compilation infrastructure to rely on the standard
CMAKE_CROSSCOMPILING_EMULATOR variable instead of the custom
CROSSCOMPILING_PATH environment hack.
Key changes:
- Removed `ENVIRONMENT "${CROSSCOMPILING_PATH}"` from all test definitions.
- Updated custom commands (e.g., H5match_types, H5_gen) to invoke the
emulator explicitly when cross-compiling.
- Updated ConfigureChecks.cmake and HDF5UseFortran.cmake to enable
`try_run` checks when an emulator is defined.
- Added config/toolchain/mingw-w64-x86-64-wine.sh wrapper to automatically
locate MinGW runtime libraries (like libgfortran) for Wine execution.
- Cleaned up toolchain files to remove hardcoded emulator paths, deferring
configuration to the build environment.
* Fix MPI Fortran configuration for HDF5Examples (#6205)
When building Fortran parallel examples standalone without MPI
wrappers, the compiler cannot find mpi.mod because
MPI_Fortran_INCLUDE_DIRS is not populated.
* Use MPI::MPI_Fortran imported target instead of raw MPI variables
Replace manual MPI_Fortran_LIBRARIES, MPI_Fortran_LINK_FLAGS, and
MPI_Fortran_INCLUDE_DIRS usage with the MPI::MPI_Fortran imported
target, which transitively carries all include dirs, compile flags,
and link flags. This eliminates the CMAKE_Fortran_EXE_LINKER_FLAGS
hack and the manual target_include_directories in H5PAR.
Addresses the "multiple @ param documentation sections" warnings are caused by the interaction of three things:
1. MACRO_EXPANSION = YES with EXPAND_ONLY_PREDEF = NO in Doxyfile.in
2. Versioned API macros in H5version.h like:
\def documentation in APIVersions.dox like:
3. \def H5Tarray_create \api_vers_2{H5Tarray_create,H5Tarray_create1,H5Tarray_create2}
Because Doxygen expands all macros, it sees H5Tarray_create as an alias for H5Tarray_create1. It then associates documentation from both the \def block (for the macro) and the function's own doc block (with \param entries) with the same function — resulting in "multiple @ param documentation sections."
* Update Doxygen version from 1.16.0 to 1.16.1
Use Doxygen 1.16.1 for all platforms. This version includes the latest
bug fixes and improvements while maintaining compatibility with our
documentation format.
* Fix Windows Doxygen installation for version 1.16.1
Handle different Windows binary naming conventions across Doxygen versions:
- 1.16.1 uses: doxygen-VERSION.windows.x64.bin.zip
- 1.16.0 uses: doxygen-VERSION.x64.bin.zip
Try the newer naming convention first, then fall back to the older one
if the download fails. This ensures compatibility across versions.
* Use ssciwr/doxygen-install in setup-doxygen action
Replace direct installation of official Doxygen binaries with
ssciwr/doxygen-install action. This avoids Java documentation parsing
errors that occur with official binaries but not with distribution
builds.
The setup-doxygen action now serves as a thin wrapper around
ssciwr/doxygen-install@f13be16c83 (v1),
using commit hash for security and reproducibility.
* Remove redundant version specification from workflows
The setup-doxygen action already has a default version (1.16.1),
so explicit version specification in workflows is unnecessary.
This follows DRY principles and makes version updates simpler.
* Advance version to 2.1.1 after creating release branch for 2.1.0
release.
* Update develop branch version to 2.2.0
Clean 2.1.0 entries from CHANGELOG.md
* Add notice for removing alternate release tag to CHANGELOG.md.
Fix typo.
* Fix typo
* Reorder AGE and REVISION for consistent order for all libraries.
* Temporarily remove develop branch restrictions from workflows.
* Revert "Temporarily remove develop branch restrictions from workflows."
This reverts commit abc7039fc5.
When building Fortran parallel examples without MPI wrappers, the
compiler couldn't find mpi.mod because MPI_Fortran_INCLUDE_DIRS
was not populated. This occurred because find_package(MPI) was only
called for C, not Fortran.
Added enable_language(Fortran) and find_package(MPI REQUIRED
COMPONENTS Fortran) to properly configure MPI for Fortran examples,
ensuring MPI include directories and libraries are correctly set.
User report:
When a file is corrupted such that an array datatype's size, the number of elements,
and the element size are not in agreement, it can trigger an out of bounds read.
(private GH issue: GHSA-gh44-7wpq-622f)
Added a validation to ensure the above are in agreement.
Ubuntu Clang tests had problems when using KyleMayes/install-llvm-action to install Clang 18.1 on Ubuntu 24.04, because the Clang that it installed needed libtinfo5 not present in the Ubuntu 24.04 image. However, Clang 18.1.3 is part of the Ubuntu 24.04 image and is used when CMAKE_C_COMPILER and CMAKE_CXX_COMPILER are set to "clang" and "clang++".
jhendersonHDF
Scot Breitenfeld
Aleksandar Jelenak
H. Joe Lee
dependabot[bot]
Lori Cooper
Gerd Heber
bmribler
Matt L
Guido Imperiale
Larry Knox
Harish RS
Martin Diehl
Julien Schueller
SY Wang
Neil Fortner