gmxapi may over-manage RPATH
The RPATH settings we have for libgmxapi look either like defaults or things that are artefacts of developing outside the main GROMACS project. We should simplify these, or document what they are intended to achieve.
Disable gmxapi by default
Due to outstanding issues with the integration testing and tests failing
with large number of ranks, the gmxapi default has been changed to not
be build. In Jenkins, all supported builds still are still set to build
with GMXAPI enabled.
#1 Updated by Mark Abraham about 1 year ago
In particular, when building with clang+cuda+ninja, I get
CMake Error at src/api/cpp/CMakeLists.txt:53 (add_library): The install of the gmxapi target requires changing an RPATH from the build tree, but this is not supported with the Ninja generator unless on an ELF-based platform. The CMAKE_BUILD_WITH_INSTALL_RPATH variable may be set to avoid this relinking step.
which I can get rid of if I comment out
set_target_properties(gmxapi PROPERTIES BUILD_WITH_INSTALL_RPATH FALSE)
so unless the later has a clear use, then we should probably drop it.
#8 Updated by Eric Irrgang about 2 months ago
- Target version changed from 2020 to 2020-beta3
We should be able to resolve this with less effort when we move to the new testing infrastructure, but the appropriate test coverage is pretty broad.
Note that some of these CMake config options predate the current CMake policy behaviors and GROMACS choices, but originally they could affect both how libgmxapi finds libgromacs and how libgmxapi clients find libgmxapi (or how the libgmxapi ability to find libgromacs could be affected by how libgmxapi is loaded by a client.)
I believe that the behavior we want is that (a) libgmxapi is built so that libgromacs is at a fixed location relative to itself at build through to install, that (b) the installed libgmxapi (and imported CMake target) provide the necessary information for client code to resolve the libgmxapi location via the client RPATH (or equivalent facility). I don't think we need to support relocatability of the libgmxapi installation, but if we do, it doesn't seem like much to ask clients linked against the first location to have to relink against the new location. We do need to allow client code to be relocatable without relinking because of how various packaging systems work, which has slight constraints on how the library identifies itself and what RPATH hinting is provided through CMake.
Note that, currently, we do not produce an installable binary package of client software (such as the Python gmxapi package or the sample_restraint MD extension) in the GROMACS build tree. If we did, we would need to consider that the package would have to be built in an environment where its ultimate link targets are not yet available.
- Linux (multiple binary formats?)
- Mac OS X
- Windows? (please no)
Assume libgromacs state == libgmxapi state
- in build tree (BUILD_INTERFACE and library target)
- installed (INSTALLED_INTERFACE and imported target)
- _gmxapi target in build tree (e.g. with gmxapi_pytest target)
- Python gmxapi package building and linking against GROMACS installation in packaging sandbox.
- Python gmxapi package relocated during package installation.
- sample_restraint target tested in GROMACS build tree.
- sample_restraint package installed in user environment.
#10 Updated by Mark Abraham 4 days ago
We haven't ever designed for supporting multiple binary/linking formats (e.g. ELF, DWARF) and definitely not mixing them, so the only thing we should consider now is testing with the toolchain provided by the user and that means we have to assume it's capable of correct behavior and issuing a message when it can't.
Since Windows has never been tested with GMXAPI, we should give an error from src/CMakeLists.txt if someone tries it (not just default off).
Otherwise, Erik's matrix looks fine. We need scripts that can cover those cases, whether we run them manually or automated. Once we have them, then it's easier to see whether things in src/api/cpp/CMakeLists.txt are necessary or not.