Issues when using HDF5 as a git submodule and using CMake with add_subdirectory

HDF5 Library
1

First off great job to all hdf5 developers and contributors. It is really a spectacular piece of software.

I am developing a software package using CMake and git. I have added the hdf5 repository, https://bitbucket.hdfgroup.org/scm/hdffv/hdf5.git, as a git submodule and have checked it out to tag “hdf5-1_12_0” (is that the correct tag for the release?). I add hdf5 to my project using add_subdirectory. I then link my executables setting target_link_libraries and target_include_directories. Everything mostly works, but there are a couple pain points that if resolved could make incorporating HDF5 into CMake projects a much more pleasant experience.

  • It would be great if targets such as “hdf5-shared” or “hdf5-static” would have their include directories set as public so they would automatically be picked up by any targets that include them. Now i Have to set the include directories manually to ${CMAKE_BINARY_DIR}/hdf5 for each target that I want to link with hdf5

  • When I have added HDF5 as sub directory to my CMake project all of the default output directories are hijacked by HDF5. CMAKE_ARCHIVE_OUTPUT_DIRECTORY, CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_PDB_OUTPUT_DIRECTORY are all changed which affects all other targets in my project. This results in executables not related to hdf5 being placed in hdf5/bin/. I have worked around this by resetting the various CMAKE directories after my add_subdirectory call. It would be nice if the HDF5 cmake build system didn’t change these variables in the parent/global scope.

  • Anytime I change or edit my top level CMakeLists.txt (even white space changes) a rebuild of the hdf5 libraries is triggered. I think this is due to the hdf5 configuration being at least partially re-triggered. This changes the time stamp for generated headers (even though there is no real change). The affected headers are H5Edefin.h, H5Einit.h, H5pubgen.h, H5Eterm.h. It would be nice if the configuration process wasn’t triggered every time there is an unrelated change to an unrelated CMakeLists.txt file.

  • This is related to the previous bullet. H5Edefin.h, H5Einit.h, H5pubgen.h, H5Eterm.h are generated during the configuration process, but are not ignored in .gitignore so the submodule is in a “dirty” state when you build the project. It would be nice if by default these files were ignored on the release tags such as “hdf5-1_12_0”.

  • There are a lot warnings when building the hdf5 libraries, It would be nice to have a CMake option to turn off warnings for the hdf5 libraries to quite down the build.

If helpful I could put together an example project demonstrating these issues.

1 Like
2

Yes, we are aware of the issues regarding use in add_subdirectory - understand that the CMake implementation was designed to be used in an ExternalProject call. One of the next enhancements will be use in add_subdirectory.

The problem with the H5E* headers is that the option for generating those headers was left enabled in release code. We hope to correct that in the future. See: HDF5_GENERATE_HEADERS

For warnings try: HDF5_DISABLE_COMPILER_WARNINGS
we are working towards reducing warnings - it is a slow process. Current development has started to move some warnings to errors.

Allen

1 Like
3

Hi Allen,

Thank you for the reply. Glad to hear that CMake add_subdirectory improvements are on the roadmap.

Your suggestion about the two options solved the biggest pain points for me.Thank you so much.

For others looking for solutions I have these two lines before my add_subdirectory call for HDF5

set(HDF5_GENERATE_HEADERS OFF CACHE BOOL "Turn off header generation for HDF5" FORCE)
set(HDF5_DISABLE_COMPILER_WARNINGS ON CACHE BOOL "Turn off HDF5 compiler warnings" FORCE)
4

This is working, as proof see Update to match develop and allow hdf5 as subdirectory build by byrnHDF · Pull Request #49 · HDFGroup/hdf5-examples · GitHub
It is using fetch_content and setting some variables, but believe this is acceptable.