Project

General

Profile

Task #988

Updated by Teemu Murtola over 5 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 http://www.gromacs.org/Developer_Zone/Programming_Guide/Doxygen)
* 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?

Back