Task #988

Updated by Teemu Murtola about 6 years ago

One of the goals stated on the wiki for 5.0 is for @libgromacs@ libgromacs to behave more like a real library. To this end, we should think about what we want to expose as the "public API" of @libgromacs@ libgromacs and how fixed are we ready to keep those parts between releases.

There are at least the following aspects to consider:
* Which symbols (classes/functions/types) we want to export from our shared library/libraries? (see #701)
* Which symbols we document as being part of our public API? (see Doxygen documentation instructions in the Doxygen-generated documentation for the current approach) (related to
* Which symbols are declared in installed headers?
** Should symbols that are not part of a public API, but are declared in installed headers, be within a separate namespace such as @internal@ or @detail@?
* Which symbols are used in our executables?
* What is the division between the library and the executables?
Which symbols are used in our unit tests?

This issue is mostly about discussing the above aspects. The outcome should be a clear definition of how the above-mentioned aspects should relate to each other in our code.

A few points to support the discussion:
* Symbols used in installed binaries must be exported.
* Symbols used in unit tests should be exported to avoid a lot of headaches and build system complications.
* If we have our library internally divided into modules, it may also make a lot of sense to unit test also some of the interfaces between modules, even if they are not public.
* Currently, with the exception of @mdrun@ and @gmx view@, essentially all the code for the programs is within @libgromacs@, and the executable is only a shell. If we move more content into the executables, can we support things like Python bindings to the analysis tools?