[gmx-developers] some suggestion to gromacs as a library

LI Daobing lidaobing at gmail.com
Wed Jun 28 00:05:19 CEST 2006


Hello,

on Debian, gromacs provide a gromacs-dev package. And I write a
program depends on this library(only the xtc part), And I find gromacs
is hard to use as a library.

1. the X11 part is not separated from the non-X11 part
    gromacs provide 3 library, libgmx.a libgmxana.la libmd.la, but
every one depends on X11. I think separate X11 and non-X11 is better.
  because I don't like to see a lots of ldd result of my program, so I
choose use dlopen to open this library

2. 3 libraries share one include directory
  I only want to use xtcio.h, but I need to guess which library I should use.

3. name conflict
  gromacs provide 110 headers in top include directory, I think one of
the following method will improve the name conflict problem
* every header begin with gmx or gmx_
* use #include <gromacs/xxx.h> instead of #include <xxx.h> in gromacs headers

4. header_guard_name_conflict

I think following header guard is better than current, it can reduce
name conflict

#ifndef GMX_XXX_H
#define GMX_XXX_H
#endif

5. c++ gaurd

some headers do not contain c++gaurd, some contains an error one.

for example xtcio.h use CPLUSPLUS as the c++gaurd symbol, bug some c++
complier(for example g++ does not define CPLUSPLUS, it define
__cplusplus).

6. config.h should not appear in library headers.

another name conflict issue. maybe you need gmx_config.h in include
directory. but the HAVE_CONFIG_H gaurd should be removed, this one
should be in the c files.

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

7. missing const

for example, the following declaring[1] can be change to [2]
[1] extern int open_xtc(char *filename,char *mode);
[2] extern int open_xtc(const char *filename, const char *mode);

8. hide some headers

gromacs provide too many library headers, I don't think the library
users need all of them. I think some of them need not publish(not
depended by published ones) and some of them can hide into 'detail'
subdirectory (as boost did) or 'bits' subdirecory (as libstdc++ did).

9. typename conflict

you define real, matrix and other types. these type names are easy to
conflct with other parts. I think folllowing steps can improve on this
problem

a. rename all xxx type to gmx_xxx type(only for published types)
b. write a inner_typedef.h include following typedefs[1],  this header
will not publish and will be include by each library c files.
[1]   typedef struct gmx_xxx xxx;

OK, anyway gromacs's major purpose is to provide a MD program, not a
MD library. so maybe an easier way is to separate some useful part(for
example xtc) from gromacs instead of make gromacs a more beautiful
library.

but if you accpet some of the suggestions, I can help you by prepare
some patch files.


Regeard,

-- 
LI Daobing



More information about the gromacs.org_gmx-developers mailing list