[gmx-developers] Using C++ with Gromacs

[Peter Eastman]

Hi,

I'm working on trying to add OpenMM support to Gromacs (see https://simtk.org/home/openmm) 
.  I'm running into a variety of problems that I hope someone can help  
me with.

I'm trying to add a single source file to Gromacs which will take care  
of all the interaction between it and OpenMM.  Since OpenMM is written  
in C++, the file must use C++.  I've called it md_openmm.cpp.

In theory, this should be simple.  I added the line

AC_PROG_CXX

to configure.ac to enable C++ support.  Then in src/kernel/ 
Makefile.ac, I added md_openmm.cpp to mdrun_SOURCES.  When I run make,  
however, it fails with the following error:

make[3]: *** No rule to make target `md_openmm.c', needed by  
`md_openmm.o'.  Stop.

There is, of course, no such file as "md_openmm.c", nor is there any  
mention of such a file anywhere.  But somehow it's concluding that it  
wants to build md_openmm.o, and that the source file to build it from  
*ought* to be called md_openmm.c.

I also tried adding md_openmm.cpp to  
libgmxpreprocess at LIBSUFFIX@_la_SOURCES instead of mdrun_SOURCES.  If I  
do that, it successfully finds the file and compiles it.  But when I  
have md.c try to call a function defined in that file, the linker  
fails to find it.

Any advice would be very much appreciated.

I've also encountered a second problem.   simple.h contains the  
following code:

#ifndef HAVE_BOOL
#define bool int
   /* typedef int         	bool; */
#endif

HAVE_BOOL is not defined, presumably because the "bool" type is not  
supported in standard C.  But the presence of this #define causes all  
sorts of compilation errors if any Gromacs headers are included in a C+ 
+ source file.  I can sort of work around them by including the  
Gromacs headers after all other header files, then being very careful  
not to use the bool type anywhere.  But that's very fragile.  Also,  
using a #define instead of a typedef means that *any* occurrence of  
the characters "bool" will be replaced - as part of a function name,  
inside a character string, etc.  This seems almost certain to produce  
bugs at some point.  Would it make more sense to switch to using a new  
type name (e.g. gmxbool), rather than redefining a standard type to  
mean something else?

Thanks for your help!

Peter