[gmx-developers] include files / cmake

[Victor Rühle]

Hey,

The problem occurs with autotools as well. The actual problem is in 
typedefs:

#include <types/simple.h>

Which means search in the standard include dirs for types/simple.h. If 
you include from a 3rd party package like:

#include <gromacs/???.h>

This dir is not in the search path (so the workaround I mentiond is 
CPPFLAGS=-I<prefix>/include/gromacs). What it really should do is look 
in the current directory for these files:

#include "types/simple.h"

There were 1-2 more files in types that would need a fix as well (e.g. 
in trx.h it should be #include "../molfile_plugin.h")

This way you don't need the package name in the include directives. I 
already tried that with an older gromacs version where it worked 
perfectly, if you're interested in a patch, I can email it the next days.

Cheers,
Victor

David van der Spoel wrote:
> Victor Rühle wrote:
>> We're developing a package for coarse-graining applications which also 
>> uses the gromacs libraries. With molfile_plugin.h missing, compiling 
>> against the gromacs installation is not possible, that's why the file 
>> should be installed.
>>
>> For such a scenario, there is an additional problem with malformated 
>> include directives in the gromacs headers (I reported this some time 
>> ago), however this can be solved by some unhandy CPPFLAGS even though 
>> GROMACS headers are in standard include directory.
>>
> 
> This is a good point that I was fighting today. Even though gromacs 
> include files are installed in $PREFIX/include/gromacs the include files 
> are referred to as
> #include "typedefs.h"
> although it works fine to compile gromacs this way, for a third party 
> package that needs to link to gromacs, this complicates matters (at 
> least with cmake). Would it be possible to include all files like 
> "gromacs/typedefs.h" ?
> 
> 
>> Cheers,
>> Victor
>>
>> Roland Schulz wrote:
>>>
>>>
>>> On Mon, Nov 30, 2009 at 11:44 AM, Victor Rühle 
>>> <ruehle at mpip-mainz.mpg.de <mailto:ruehle at mpip-mainz.mpg.de>> wrote:
>>>
>>>
>>>     p.s.: in the dev branch, the file molfile_plugin.h is not copied
>>>     during installation
>>>
>>>
>>> why does this matter?
>>> This file is a VMD include file and only included in the GROMACS 
>>> source to avoid a dependency on VMD at compile time. But it is not an 
>>> external interface to GROMACS. So I don't know why anyone would need 
>>> that include file.
>>>
>>> Roland
>>>  
>>>
>>>
>>>
>>>     Berk Hess wrote:
>>>
>>>         We can't do that, since these numbers have to match the contents
>>>         of the
>>>         moltype entry.
>>>
>>>         Berk
>>>
>>>         Victor Rühle wrote:
>>>
>>>             Hi Berk,
>>>
>>>             thanks for the quick answer. The only thing I don't
>>>             understand then is
>>>             the t_block structure mtop.mols which contains at least the
>>>             correct
>>>             partitioning of atoms into molecules (also in the old tpr
>>>             files).
>>>
>>>             Since this data is there, wouldn't it be better to
>>>             initialize the
>>>             mtop.nmolblock.natoms_mol + mtop.nmolblock.nmol accordingly?
>>>
>>>             Victor
>>>
>>>             Berk Hess wrote:
>>>
>>>                 Hi,
>>>
>>>                 The old tpr files do not  contain information on
>>>                 molecular topologies,
>>>                 so the only thing we can do is consider the whole system
>>>                 as one large
>>>                 moleculetype.
>>>
>>>                 Berk
>>>
>>>                 Victor Rühle wrote:
>>>
>>>                     Dear all,
>>>
>>>                     I changed my code for reading .tpr files to read_tpx
>>>                     to get molecule
>>>                     names. When I use the tpr-file generated by a recent
>>>                     gromacs version,
>>>                     everything works fine.
>>>
>>>                     However when using older .tpr files (before molecule
>>>                     names were
>>>                     stored), there is an inconsistency in the 
>>> structures:
>>>
>>>                     mtop.nmolblock = 1
>>>                     mtop.nmoltype = 1
>>>
>>>                     mtop.molblock[0].nmol = 1
>>>                     mtop.mols.nr <http://mtop.mols.nr> = real number of
>>>                     molecules
>>>
>>>                     Is this a bug or a feature? As one can see, at least
>>>                     some molecule
>>>                     information is still there but just the new
>>>                     structures are not set up
>>>                     properly. If I run tpbconv, it puts all atoms in a
>>>                     single molecule.
>>>
>>>                     Possible workarounds are to rerun grompp to create
>>>                     new tpr files or
>>>                     change my read function to compensate for this
>>>                     problem. Both solutions
>>>                     are not very nice.
>>>
>>>                     Did anybody else had a similar problem?
>>>
>>>                     Thanks for your help,
>>>                     Victor
>>>
>>>
>>>
>>>     --     gmx-developers mailing list
>>>     gmx-developers at gromacs.org <mailto:gmx-developers at gromacs.org>
>>>     http://lists.gromacs.org/mailman/listinfo/gmx-developers
>>>     Please don't post (un)subscribe requests to the list. Use the www
>>>     interface or send it to gmx-developers-request at gromacs.org
>>>     <mailto:gmx-developers-request at gromacs.org>.
>>>
>>>
>>>
>>>
>>> -- 
>>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov 
>>> <http://cmb.ornl.gov>
>>> 865-241-1537, ORNL PO BOX 2008 MS6309
>>>
>>
> 
>