FindGROMACS.cmake version detection
Currently, share/template/cmake/FindGROMACS.cmake hardcodes several function names, one for each version of Gromacs that it can identify, and uses a series of check_library_exists() with these to detect the version. This requires adding such a function for each new version, which requires extra maintenance and can become more and more complex if the code moves to C++. Additionally, the current logic is confusing (although correct) in that it uses
init_domdec_vsites: this function exists already in Gromacs 4.6, but in
libmd, which isn't linked in while doing the checks (unless the user overrides the libraries).
gromacs/version.h has existed, and would provide a simpler way for detecting the exact version. The header is automatically updated by the build system, at least until we reach a level of API stability that we may actually confidently say that we can keep the API version fixed between some releases, so this would hopefully reduce maintenance. An approach similar to what FindBoost.cmake does with
boost/version.hpp should work relatively well here as well.
Use native CMake mechanism for find_package(GROMACS)
Instead of various detection stuff that only worked well in the presence
of pkg-config, use native CMake mechanisms: package configuration files
and automatic export of library import definitions. Include
directories and preprocessor macros influencing the installed headers
are still propagated separately. The new mechanism also works for
arbitrary suffixes, and is relocatable (as long as external libraries
that GROMACS links against are not moved). A simple FindGROMACS.cmake
is still there to hide some of the complexity to support multiple
suffixes, but it is not strictly necessary if the using code wants to do
those slightly more complex find_package() invocations directly.
Generalize the machinery that populated libgromacs.pc to use it also for
TODO for later (requires changes that are better done outside this
- Improve the versioning logic
The machinery and its current limitations are documented in the Doxygen
page on using GROMACS as a library. Some of these could possibly be
improved with additional effort, but the current approach is hopefully a
reasonable compromise between usability, robustness, and complexity.