CMake `gmxapi` package should account for multiple GROMACS flavors installed to the same prefix.
Summary
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 find_package(gmxapi)
and find_package(gromacs*)
.
Installing GROMACS builds (for GMX_DOUBLE=OFF/ON
, 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
-DGMXAPI=ON
). - Choose options for a different build configuration (different suffix), and install again with the same
CMAKE_INSTALL_PREFIX
. - Note that
-
$CMAKE_INSTALL_PREFIX/share/cmake/gmxapi/gmxapi-config.cmake
sets target properties related to the MPI flavor -
gmxapi-<build type>.cmake
references a singlelibgmxapi
flavor. -
gmxapi-<build type>.cmake
notes the dependency onGromacs::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?
What happens?
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 GROMACS_DIR
, GMXTOOLCHAINDIR
, or other hinting mechanisms.
Possible fixes
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.