[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