[gmx-developers] future of installed headers and libraries

[David van der Spoel]

On 2014-07-07 07:48, Mark Abraham wrote:
> Hi,
>
> 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.

As part of a QM/MM implementation (in the qmmm branch) I'm developing an 
API for using gromacs as a slave calculator, with a data structure and a 
few calls. The idea is that the application includes the header file 
(just one) and then can use "Gromacs In A Box". This will also be useful 
for e.g. writing a Monte Carlo code or docking code in C++ or python. 
Obviously all such new codes should come with unit tests and where 
appropriate regression tests.

What I want to say with this is that I agree we move all the "legacy" 
headers out of the installation successively and replace them with 
useful APIs as we go along. Of course this should only happen between 
significant updates not bug-fix patches.


>
> 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
> libraries.
>
> 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 grompp.
>
> 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.
>
> Cheers,
>
> Mark
>
>
>


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se