Hi Sebastian and Michael, Sorry for the confusion that TargetHDF5 files have caused. The short answer is that TargetHDF5 is just the results of normal HDF5 detection wrapped in a target and written to a TargetHDF5Config.cmake file. It’s necessary for sharing dependencies in a CMake superbuild. TargetHDF5*cmake files (as opposed to HDF5*cmake) are homespun by Psi4 and thus won’t interfere with anything else (unless they’ve taken up the prefix Target). I’m not sure of the legitimacy of this cmakeification either, but until the sources of HDF5 (OS, etc.) and the project itself provides a HDF5Config.cmake file, this is the lightest intervention I could devise. If you want the full justification, read on. If this is unclear, please poke me again.
History: HDF5 and LAPACK projects have flavors of FindHDF5.cmake and FindLAPACK.cmake files that are provided by Kitware or 3rd-party. These have to be able to hunt down the libraries/headers on a variety of systems, possibly also seeking support for different language interfaces or parallelism support, thus they are very complex and may require a large number of input specifications to be totally reproducible when run again, even in the same CMake configuration session. Moreover, these particular packages return their findings in CMake variables (semicolon-separated lists), rather than a CMake target that packages them all together. Targets are more compact and, more importantly, CMake respects their integrity and won’t “optimize away” repeated libraries or flags that are sometimes required, esp. for LAPACK. The alternative to FindProject.cmake is ProjectConfig.cmake which is instead distributed along with the project and so provides exactly the location and features of the accompanying particular compilation. This is firstly much shorter and, more importantly, can be re-read at any stage of the cmake configuration with a single variable (location of the Config file). Since Psi4 wants to share common dependencies with its addons (e.g., use specialized LAPACK detection and then let libefp use the results, too, rather than `find_package(LAPACK)`), that requires they be a target (not variables) and findable with `find_package(... CONFIG)` (not a FindPackage.cmake). Since HDF5 and LAPACK don’t provide these (the situation is getting better, but until RHEL etc. distributes them widely, still no good), Psi4 provides a light wrapper that runs FindHDF5, collects the variables, composes a target, writes a TargetProjectConfig.cmake. On the addon side, `find_package(PROJECT)` is replaced by `find_package(TargetPROJECT CONFIG)` that looks for the pre-detected TargetProjectConfig.cmake written by Psi4, then falls back to ordinary `find_package(PROJECT)` so that the addon is fully useable w/o pieces from Psi4. Even if using an installed version of the addon and using AddonConfig CMake detection that has `tgt::hdf5` written into it, sufficient files are written so that it can fall back to the generic `find_package(HDF5)`. Sincerely, Lori
