Hi Michael and Lori, Lori: First of all, thank you for the clarification below.
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 > Michael: I guess that it cannot hurt to ship the TargetHDF5*.cmake file(s) as it is/they are "homespun by Psi4"? Additionally, it is/they are also installed in a dedicated CheMPS2 folder (usr/share/cmake/CheMPS2/) and related to the specific CheMPS2 build. Best wishes, Sebastian