Split static targets into separate optional target [UPDATED] by brtnfld · Pull Request #6216 · HDFGroup/hdf5

brtnfld · 2026-02-12T20:44:57Z

Supersedes #6109

Additions:

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.

Important

Split static targets into separate optional targets in HDF5 CMake configuration, removing global variables and fixing static-only build issues.

Behavior:
- Export static and shared targets separately in CMakeInstallation.cmake and hdf5-config.cmake.in.
- Fix static-only build bug by ensuring base export set is not guarded by BUILD_SHARED_LIBS.
Variables:
- Remove global variables HDF5_STATIC_LIBRARIES_TO_EXPORT, HDF5_JAVA_LIBRARIES_TO_EXPORT, HDF5_UTILS_TO_EXPORT.
CMake Targets:
- Add separate export targets for static libraries in c++/src/CMakeLists.txt, fortran/src/CMakeLists.txt, and hl/c++/src/CMakeLists.txt.
- Update install() commands to handle static and shared targets separately in src/CMakeLists.txt and tools/lib/CMakeLists.txt.

^{This description was created by}^{for 53710f2. You can customize this summary. It will automatically update as commits are pushed.}

mattjala · 2026-02-13T18:11:10Z

c++/src/CMakeLists.txt

+        TARGETS
+            ${install_targets_shared}
+        EXPORT
+            ${HDF5_EXPORTED_TARGETS}


It seems like the current pattern for this is ${HDF5_EXPORTED_TARGETS} for shared exports, and ${HDF5_EXPORTED_TARGETS}_static for static exports. This is slightly different than the naming pattern for the other shared vs. static variables, where the shared-specific one is suffixed with _shared. It might be good to use that pattern here too.

The EXPORT argument directly controls the generated CMake file names:

EXPORT ${HDF5_EXPORTED_TARGETS} -> ${HDF5_PACKAGE}-targets.cmake (primary)
EXPORT ${HDF5_EXPORTED_TARGETS}_static -> ${HDF5_PACKAGE}-static-targets.cmake (variant)

By CMake convention, the base export set name (without suffix) represents the primary/default build artifact (shared libraries), while suffixed names are for variants. Changing the shared export to _shared would generate ${HDF5_PACKAGE}-shared-targets.cmake, breaking this convention and potentially affecting downstream consumers who expect the standard naming convention.

The asymmetry with install_targets_shared/install_targets_static is intentional—those are internal variables, while export set names follow external packaging conventions.

mattjala · 2026-02-13T18:14:07Z

CMakeLists.txt

+# Used by hdf5-config.cmake.in to advertise available library targets
 #-----------------------------------------------------------------------------
 set_global_variable (HDF5_LIBRARIES_TO_EXPORT "")
-set_global_variable (HDF5_UTILS_TO_EXPORT "")


Does removing this global change the export behavior? It doesn't seem like this was replaced with anything

HDF5_UTILS_TO_EXPORT was intentionally removed and replaced by the CMake export set mechanism. The refactoring changed from manual tracking (export(TARGETS ${HDF5_UTILS_TO_EXPORT}...)) to automatic export sets (export(EXPORT ${HDF5_EXPORTED_TARGETS})). Since tools already have EXPORT in their install() commands, they're automatically included. This ensures build-tree and install-tree exports are identical.

See my other comment; I believe this could be an unexpected change in behavior.

config/install/hdf5-config.cmake.in

jhendersonHDF · 2026-02-18T19:56:48Z

CMakeInstallation.cmake

+  endif ()
  export (
-      TARGETS ${HDF5_LIBRARIES_TO_EXPORT} ${HDF5_LIB_DEPENDENCIES} ${HDF5_UTILS_TO_EXPORT}
+      EXPORT ${HDF5_EXPORTED_TARGETS}


I believe this is a change in behavior because a project building the library as a sub-project could unset HDF5_EXPORTED_TARGETS, in which case none of the targets would be available for export at all whereas previously they were. I'm assuming the previous behavior is intended because only the logic above is guarded by if (HDF5_EXPORTED_TARGETS) whereas this export() call isn't. I don't think ${HDF5_EXPORTED_TARGETS} should be used here since it could be unset.

However, looking closer at the logic, I also believe this export () call should be moved outside of the enclosing if (NOT HDF5_EXTERNALLY_CONFIGURED), as the comment about the parent project makes no sense otherwise.

CMakeLists.txt

…5_UTILS_TO_EXPORT - Move build-tree export(TARGETS) outside if(NOT HDF5_EXTERNALLY_CONFIGURED) so sub-project builds can access targets in the build tree - Use export(TARGETS) with global variables instead of export(EXPORT) to avoid dependency on HDF5_EXPORTED_TARGETS which could be unset by parent - Restore OPTIONAL on static targets include (needed for build-tree config where all targets are in a single combined file) - Keep OPTIONAL on Java targets include - Restore original comment and HDF5_UTILS_TO_EXPORT global variable - Re-add set_global_variable(HDF5_UTILS_TO_EXPORT) calls in tool/util files

opoplawski · 2026-02-22T03:41:57Z

config/install/hdf5-config.cmake.in

  endif ()
  include (@PACKAGE_SHARE_INSTALL_DIR@/@HDF5_PACKAGE@@HDF_PACKAGE_EXT@-targets.cmake)
+  if ( @BUILD_STATIC_LIBS@ AND @BUILD_SHARED_LIBS@ )
+    include (@PACKAGE_SHARE_INSTALL_DIR@/@HDF5_PACKAGE@@HDF_PACKAGE_EXT@_static-targets.cmake)


This needs to be OPTIONAL if we are going to be able to split the static-targets.cmake into a separate -static sub-package.

I guess it's still a bit unclear to me why this needs to be OPTIONAL. The only time the file should be missing is when BUILD_STATIC_LIBS is OFF, in which case include() shouldn't get called here.

Ah ok, going back to your original comment about the sub-package being shipped separately I understand the need for OPTIONAL here now. It seems less than ideal though considering it would mask actual problems in the case where the static-targets file is missing due to an issue in our logic, but I don't have a good solution currently.

@brtnfld We should put OPTIONAL back here and maybe include a comment in the file mentioning that some packages ship HDF5 in such a way that the individual targets files may not be available.

Yeah, it's not great. Perhaps there could be a run time determination if BUILD_STATIC is set?

opoplawski · 2026-02-22T03:47:03Z

Thanks a lot for continuing the work on this. It will be very useful for the Fedora package.

Replace bare include() calls with explicit if(EXISTS) checks and use runtime variables instead of configure-time substitutions for the static and Java target guards. Core and vendored dependency targets (ZLIB, SZIP) fail gracefully via CMAKE_FIND_PACKAGE_NAME_FOUND=FALSE with an actionable error message when files are missing, since HDF5 targets depend on them through INTERFACE_LINK_LIBRARIES. Static and Java targets degrade gracefully by clearing their PROVIDES_* flags when files are missing (e.g. distros that only ship shared libraries), allowing check_required_components() to report the correct error if the user requested those components. All temporary variables are unset after use to prevent leakage into downstream scopes.

# Conflicts: # CMakeFilters.cmake

brtnfld · 2026-02-24T19:41:11Z

config/install/hdf5-config.cmake.in

+  if (${HDF5_PACKAGE_NAME}_PROVIDES_STATIC_LIBS AND ${HDF5_PACKAGE_NAME}_PROVIDES_SHARED_LIBS)
+    include ("@PACKAGE_SHARE_INSTALL_DIR@/@HDF5_PACKAGE@@HDF_PACKAGE_EXT@_static-targets.cmake" OPTIONAL RESULT_VARIABLE _hdf5_static_loaded)
+    if (NOT _hdf5_static_loaded)
+      set (${CMAKE_FIND_PACKAGE_NAME}_static_FOUND FALSE)


Setting this hooks into CMake's native error-handling for find_package(), so the missing dependency occurs at configure-time rather than letting the application stumble into a cryptic target-not-found error at link-time at the near end of the build.

…p#6216) 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.

* Skip some parallel example tests for small MPIEXEC_MAX_NUMPROCS values (#6224) * chore: fix grammar (#6227) * Split static targets into separate optional target [UPDATED] (#6216) 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. * Apply filters to variable-length data (#6178) 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).

brtnfld added 2 commits February 10, 2026 17:32

addresses core DRY concern

2678055

Kept HDF5_LIBRARIES_TO_EXPORT

53710f2

brtnfld requested review from jhendersonHDF and mattjala as code owners February 12, 2026 20:44

github-project-automation bot added this to HDF5 - TRIAGE & TRACK Feb 12, 2026

brtnfld requested review from bmribler, derobins, epourmal, fortnern, glennsong09, lrknox, qkoziol and vchoi-hdfgroup as code owners February 12, 2026 20:44

github-project-automation bot moved this to To be triaged in HDF5 - TRIAGE & TRACK Feb 12, 2026

Merge branch 'develop' into 6109

26170a1

brtnfld assigned jhendersonHDF Feb 12, 2026

brtnfld moved this from To be triaged to In progress in HDF5 - TRIAGE & TRACK Feb 12, 2026

brtnfld added this to the HDF5 2.x.x milestone Feb 12, 2026

bmribler previously approved these changes Feb 13, 2026

View reviewed changes

mattjala reviewed Feb 13, 2026

View reviewed changes

updated the changlog

0bd0fdc

brtnfld dismissed bmribler’s stale review via 0bd0fdc February 13, 2026 23:13

bmribler added the Component - Build CMake files label Feb 16, 2026

brtnfld requested review from bmribler and mattjala February 17, 2026 05:35

mattjala previously approved these changes Feb 17, 2026

View reviewed changes

jhendersonHDF reviewed Feb 18, 2026

View reviewed changes

config/install/hdf5-config.cmake.in Outdated Show resolved Hide resolved

jhendersonHDF reviewed Feb 18, 2026

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

brtnfld force-pushed the 6109 branch from add9fef to 28c7063 Compare February 18, 2026 21:44

brtnfld force-pushed the 6109 branch from 28c7063 to e01f435 Compare February 18, 2026 21:48

brtnfld force-pushed the 6109 branch from e01f435 to eeb0bf8 Compare February 18, 2026 21:50

brtnfld force-pushed the 6109 branch from eeb0bf8 to 31a2b7c Compare February 18, 2026 22:01

brtnfld force-pushed the 6109 branch from 31a2b7c to bf86955 Compare February 18, 2026 22:16

opoplawski reviewed Feb 22, 2026

View reviewed changes

brtnfld force-pushed the 6109 branch from 095153c to 5d7c196 Compare February 23, 2026 21:54

brtnfld force-pushed the 6109 branch from 5d7c196 to 1f6e01e Compare February 23, 2026 22:12

Merge remote-tracking branch 'origin/develop' into 6109

1fe7d70

# Conflicts: # CMakeFilters.cmake

brtnfld force-pushed the 6109 branch from 4514885 to 1fe7d70 Compare February 24, 2026 01:06

brtnfld modified the milestones: HDF5 2.x.x, HDF5 2.1.0 Feb 24, 2026

brtnfld requested review from jhendersonHDF and mattjala February 24, 2026 18:46

brtnfld commented Feb 24, 2026

View reviewed changes

jhendersonHDF approved these changes Feb 24, 2026

View reviewed changes

lrknox approved these changes Feb 24, 2026

View reviewed changes

lrknox merged commit a7ec64a into HDFGroup:develop Feb 24, 2026
140 checks passed

github-project-automation bot moved this from In progress to Done in HDF5 - TRIAGE & TRACK Feb 24, 2026

brtnfld mentioned this pull request Feb 25, 2026

Split static targets into separate optional target #6109

Closed

Uh oh!

Conversation

brtnfld commented Feb 12, 2026 • edited by ellipsis-dev bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jhendersonHDF Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jhendersonHDF Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

opoplawski commented Feb 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

brtnfld commented Feb 12, 2026 •

edited by ellipsis-dev bot

Loading

jhendersonHDF Feb 18, 2026 •

edited

Loading

jhendersonHDF Feb 23, 2026 •

edited

Loading