Install ZFP filter shared library to lib/plugin instead of plugin#270
Conversation
H5Z-ZFP/src/CMakeLists.txt (vendored via subtree) hardcodes the shared plugin's install destination to plugin, instead of following this project's lib/plugin convention. Relocate the installed file at install time so libh5zzfp.so lands in /lib/plugin like every other filter, without patching the vendored subtree.
|
Additional fix needed for a packaging test failure on ubuntu. |
CPack (e.g. the DEB generator used by the Ubuntu CI job) stages
installs into while leaving CMAKE_INSTALL_PREFIX at its
literal configured value. install(TARGETS)/install(FILES) handle this
automatically via the DESTDIR-aware file(INSTALL), but the plain
file(MAKE_DIRECTORY)/file(RENAME) calls added to relocate libh5zzfp.so
did not, so packaging tried to create/rename outside the staging tree
and failed with 'No such file or directory'. Prepend {DESTDIR} by
hand to match.
|
All tests now pass. |
| file(RENAME | ||
| \"\${_h5zfp_destdir}/plugin/$<TARGET_FILE_NAME:h5z_zfp_shared>\" | ||
| \"\${_h5zfp_destdir}/${H5ZFP_INSTALL_LIB_DIR}/$<TARGET_FILE_NAME:h5z_zfp_shared>\") | ||
| ") |
There was a problem hiding this comment.
With the file renaming logic, this seems quite a bit like hacking around the ZFP code and also doesn't seem particularly maintainable; changing the installation prefix should have been as easy as setting a CMake variable before the add_subdirectory call. If that's not the case, we should be able to make a PR to the ZFP code so that's possible.
There was a problem hiding this comment.
claude says that because "plugin" is a literal string in these lines 62 - 64 of ZFP/H5Z-ZFP/src/CMakeLists.txt:
install(TARGETS h5z_zfp_shared
RUNTIME DESTINATION plugin
ARCHIVE DESTINATION plugin
LIBRARY DESTINATION plugin)
setting a variable beforehand won't have any effect. We'll need a PR to change "plugin" to a variable in those lines in src/CMakeLists.txt in the ZFP code?
There was a problem hiding this comment.
Yes I think the ZFP code should allow overriding the install destination. If GNUInstallDirs is followed, then it should probably be ${CMAKE_INSTALL_LIBDIR}/plugin by default anyway, unless the project wants to keep $prefix/plugin as the default.
…ting after install H5Z-ZFP/src/CMakeLists.txt now honors H5Z_ZFP_PLUGIN_INSTALL_DIR (default "plugin", unchanged for standalone builds) instead of hardcoding the shared plugin's install destination. The wrapper sets it to H5ZFP_INSTALL_LIB_DIR before add_subdirectory(), replacing the install(CODE ...) rename/DESTDIR workaround from the previous commit. This mirrors a change proposed upstream to LLNL/H5Z-ZFP. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3 participants
H5Z-ZFP/src/CMakeLists.txt (vendored via subtree) hardcodes the shared plugin's install destination to plugin, instead of following this project's lib/plugin convention. Relocate the installed file at install time so libh5zzfp.so lands in /lib/plugin like every other filter, without patching the vendored subtree.