CMake `gmxapi` package should account for multiple GROMACS flavors installed to the same prefix.
In release-2019 through release-2022, C++ headers and library have been managed with a
gmxapi CMake target, installed with a CMake
gmxapi "config-file package", providing the
Gromacs::gmxapi imported target.
The installed CMake config package files reflect a single
Gromacs::gmxapi target that depends on a single
Gromacs::libgromacs target. However,
Gromacs::libgromacs can be provided by different packages installed to the same prefix.
When multiple flavors of GROMACS are installed to the same prefix, the config file package support for
Gromacs::gmxapi is overwritten.
This can cause confusion, especially for client software that includes both
Installing GROMACS builds (for
GMX_MPI=OFF/ON, etc) to the same prefix should not destroy the ability of
find_package(gmxapi) to locate the previous installation.
Exact steps to reproduce
- Configure and install GROMACS (without disabling
- Choose options for a different build configuration (different suffix), and install again with the same
- Note that
$CMAKE_INSTALL_PREFIX/share/cmake/gmxapi/gmxapi-config.cmakesets target properties related to the MPI flavor
gmxapi-<build type>.cmakereferences a single
gmxapi-<build type>.cmakenotes the dependency on
Gromacs::libgromacs, but does not indicate the package variant to provide it.
For developers: Why is this important?
It is supposed to be possible to install multiple GROMACS builds to the same location, distinguished by suffix. The current behavior of the
Gromacs::gmxapi component is inconsistent with that practice and causes confusion when trying to
pip install gmxapi or to build other client software.
The consensus is that this is a bug, so @eirrgang will lead the effort to patch currently supported GROMACS releases.
If this is a bug, (1) what happens, and (2) what did you expect to happen?
find_package(gmxapi) reflects only the most recent installation of the GROMACS gmxapi library component.
What did you expect to happen?
find_package(gmxapi) finds config files for the libraries corresponding to
GMXTOOLCHAINDIR, or other hinting mechanisms.
The most obvious solution includes separating out (from
gmxapi-config.cmake) any configuration-specific details that would be overwritten on a subsequent installation. However, minor additions will be appropriate to allow all installed configurations to be discoverable.
We can use some combination of CMake "configurations" and "components".
We could either require the user to specify a mutually exclusive component to
find_package in order to return a selected version of the
Gromacs::gmxapi target, or we could switch to distinctly-named targets and make all flavors available.
Since only one
Gromacs::libgromacs target can exist, and since we hope that we can some day provide multiple build flavors to the same client at a time, @eirrgang proposes that we select a provider of the
Gromacs::gmxapi target according to a component requested by the user. (This is similar to the solution proposed in #3777 (closed))
If there are technical challenges resolving ambiguities automatically when multiple libraries are available, the priority will be on producing an error that asks the user to be more specific about the version they want.