[gmx-developers] future of installed headers and libraries

Mark Abraham mark.j.abraham at gmail.com
Mon Jul 7 07:48:58 CEST 2014


For some time, GROMACS has installed a collection of its headers and
libraries in the hope that they might be useful to third parties. I'm not
aware of anybody actually doing so - please speak up if you know of any!
All the derivative work of which I'm aware is either a fork of the code, or
a wrapper over an executable.

Making a useful library API is a considerable amount of work, but the
discipline of doing so would have internal benefits. The existing "API"
from ~4.5 seems to me like somebody grabbed most/all of the stuff and
decided to install it. Preserving the existing API over C->C++ is next to
impossible, and it will be some years yet before anything stabilizes, so
any existing client is already going to need a re-write or three.

So, I propose we stop installing headers, install shared libraries only
where we install an executable that needs it, and stop installing static

Not needing to think about such consequences gives us more freedom in
developing. Much more importantly, it makes things take less time for
(e.g.) Teemu, Roland and I. There's several commits in Gerrit right now
that are discussing such things, and there's been plenty in the past, too.

We already have some of our I/O functionality available as separate
libraries. If we make our custom analysis functionality available, I'd much
rather do that as a Python extension, or as a contribution to a dedicated
MD-analysis project. mdrun... might never achieve a better "API" than

One consequence would be that the template analysis program would stay in
the source tree. This makes it much easier to organize its secondary
dependencies than installing stuff, then detecting attributes of installed
stuff so a build can work, and all the while hoping that C++ compiler
incompatibility isn't just going to kill the third-party developer anyway.

If someone wants such a feature, and is prepared to put considerable work
into it ahead of other GROMACS things they might do, that's great. I won't
have time to put into it in the foreseeable future.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140707/3a306f3f/attachment.html>

More information about the gromacs.org_gmx-developers mailing list