Project

General

Profile

Bug #2722

gmxapi may over-manage RPATH

Added by Mark Abraham 12 months ago. Updated 6 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
build system
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

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.

Context: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling


Related issues

Blocked by GROMACS - Task #2756: gmxapi integration testingIn Progress

Associated revisions

Revision 3fd14b5f (diff)
Added by Paul Bauer 11 months ago

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.

Refs #2765, #2722, #2756

Change-Id: I2cc42c461edc206aaa30be6cac3db0a52ccae991

History

#1 Updated by Mark Abraham 12 months 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.

#2 Updated by Gerrit Code Review Bot 12 months ago

Gerrit received a related patchset '1' for Issue #2722.
Uploader: Mark Abraham ()
Change-Id: gromacs~release-2019~Ic697f596285acdb5c7728b7ebc995ea44c82f3ac
Gerrit URL: https://gerrit.gromacs.org/8632

#3 Updated by Eric Irrgang 12 months ago

I had never encountered a problem with changing RPATH between build and install directory before. Good to know.

As long as the RPATH is relative and the relationship between libgmxapi and libgromacs is consistent, removing that line should be fine.

#4 Updated by Eric Irrgang 11 months ago

  • Blocked by Task #2756: gmxapi integration testing added

#5 Updated by Gerrit Code Review Bot 11 months ago

Gerrit received a related DRAFT patchset '1' for Issue #2722.
Uploader: Paul Bauer ()
Change-Id: gromacs~release-2019~I2cc42c461edc206aaa30be6cac3db0a52ccae991
Gerrit URL: https://gerrit.gromacs.org/8801

#6 Updated by Paul Bauer 10 months ago

More likely to happen in 2020

#7 Updated by Paul Bauer 10 months ago

  • Target version changed from 2019 to 2020

#8 Updated by Eric Irrgang 6 days 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.

Matrix dimensions

Builder

  • make
  • ninja

Platform

  • Linux (multiple binary formats?)
  • Mac OS X
  • Windows? (please no)

libgmxapi state

Assume libgromacs state == libgmxapi state

  • in build tree (BUILD_INTERFACE and library target)
  • installed (INSTALLED_INTERFACE and imported target)

Client state

  • _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.

Also available in: Atom PDF