Refine CMake options and handling for installed targets
We should reconsider the semantics and processing of
BUILD_SHARED_LIBS
GMX_BUILD_MDRUN_ONLY
GMXAPI
GMX_INSTALL_LEGACY_API
The choices for SHARED or STATIC library targets are unnecessarily intertwined with the build-system-internal linking and enabled-feature choices.
Suggestion
Allow the user to choose whether installed libraries are STATIC or SHARED, but statically link internal dependencies.
Assumption
Assumes there is no compelling reason to dynamically link the gmx
or mdrun
binaries in terms of the current libgromacs.so
.
If action is ever taken on #951 (closed) or a similar issue, additional build system infrastructure will be required (e.g. new library targets) with or without the changes proposed here. Action on #951 (closed) should be simplified, though, if the installed targets are already decoupled per this proposal.
Proposal
- Separate
libgromacs
build tree target into theGromacs::libgromacs
installed target and a build-tree-onlycore
STATIC library target (with PIC enabled by default, where possible) - Make
Gromacs::libgromacs
definition and installation conditional onGMX_INSTALL_LEGACY_API
- Reduce mutually exclusive install options. Deprecate
GMX_BUILD_MDRUN_ONLY
in favor of two options:-
GMX_CLI_TOOLS
(thegmx
command line program) enabled by default -
GMX_STANDALONE_MDRUN
(baremdrun
program) disabled by default
-
- Link all installed targets against
core
instead oflibgromacs
- Let installed library targets (Gromacs::gmxapi, nblib...) respect
BUILD_SHARED_LIBS
Potential issues
- Do we need to support dynamically linked
gmx
CLI tool in terms of the current libgromacs architecture? - Are there systems of interest that support shared libraries but do not support PIC-enabled static libraries?
Edited by M. Eric Irrgang