[Debichem-devel] Bug#887104: Regarding chemps2 and psi4

[Sebastian Wouters]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20180117/868fabd2/attachment.html>