[gmx-developers] Compilation Errors When Using GROMACS Headers/Library

[Mark Abraham]

Hi,

It is normal behaviour for installed headers intended for third-party
development to expect to have their path prepended by the preprocessor, e.g.

gcc -I/usr/local/gromacs/include yourfile.c
-L/usr/local/gromacs/lib/whatever -lgromacs

This means that the same header file can be used the same way when
compiling libgromacs, so one gets some sanity for free. Otherwise, we'd
also have to run some kind of script at "make install" time that copied the
files and edited them, similar to what you have done with sed. Also, you'll
have a harder time testing your code against multiple versions of GROMACS
if you've hard-coded the path to the include files, perhaps in many places,
directly in your code - the -I option is very much your friend.

Do also be aware that libxdrfile is a thing.

Mark

On Wed, Jul 6, 2016 at 4:53 PM Vladislav Martin <martin.vl at husky.neu.edu>
wrote:

> Dear GROMACS developers,
>
> I am writing code in C utilizing the GROMACS 5.1.2 library. The purpose of
> the code is to read the binary data stored in GROMACS' XTC trajectory files
> into C data types for further analysis / manipulation of the data.
>
> *NOTE*: In case this would be important information, I followed the "Quick
> and Dirty Installation"
> <http://manual.gromacs.org/documentation/5.1.2/install-guide/index.html#quick-and-dirty-installation>
> instructions for GROMACS 5.1.2 and all commands were executed in the
> terminal successfully.
>
> Back to the C code. At the very top of my file, I include
> "/usr/local/gromacs/include/gromacs/fileio/xtcio.h" so that I may access
> the functions I need to read the XTC trajectory files. I ran into an odd
> error when attempting to compile my program.
>
> ""
> $ gcc -o read_trajectory read_trajectory.c -L
> /usr/local/gromacs/lib/x86_64-linux-gnu/ -lgromacs
> In file included from read_trajectory.c:3:0:
> /usr/local/gromacs/include/gromacs/fileio/xtcio.h:41:35: fatal error:
> gromacs/fileio/gmxfio.h: No such file or directory
>  #include "gromacs/fileio/gmxfio.h"
>                                    ^
> compilation terminated.
> ""
>
> I can fix this error by running a bash command that searches recursively
> through all header files in the "usr/local/gromacs/include/gromacs"
> directory and replaces 'gromacs/' (which only shows up in #include
> statements) with '/usr/local/gromacs/include/gromacs/' (or
> '/path/to/your/installation/gromacs/include/gromacs/'). I have included
> this bash command in case someone else experiences this compilation error
> and wants to fix it quickly:
>
> '""
> $ sudo find /usr/local/gromacs/include/gromacs/ -name '*.h' -type f -exec
> sed -i 's:gromacs/:/usr/local/gromacs/include/gromacs/:' {} \;
> ""
>
> Once I run this command, the program compiles successfully and I am able
> to run the resulting executable without any further errors.
>
> What confuses me is that this error could have been fixed when the GROMACS
> header files were created in the first place - I shouldn't have to fix the
> relative paths where the header files are supposed to look for & find the
> other GROMACS header files. From what I can tell (I read the #include
> directives
> <http://manual.gromacs.org/documentation/5.1.2/dev-manual/includestyle.html>),
> every header file is contained within the
> "/usr/local/gromacs/include/gromacs/" directory (or, more generally,
> "/path/to/your/installation/gromacs/include/gromacs/"). Within that
> directory there are modular directories that store related headers, like
> "fileio/". Knowing all of this, why does an #include statement referring to
> a GROMACS header file in that *same* directory say
> "gromacs/fileio/gmxfio.h" - which, as a relative path, would *never*
> point to the right directory - instead of "gmxfio.h" or "./gmxfio.h", which
> actually reflects this file hierarchy?
>
> In the end, my question is simple: did I miss something in the
> documentation that informs me on how to include GROMACS headers files
> properly so that I don't have to change the include statements myself?
> Otherwise, is this a syntax bug that will be fixed in later GROMACS
> versions?
>
>
> Many thanks,
>
> Vladislav Martin
> Research Assistant
> Center for Nanobiology and Structural Biology
> Email: martin.vl at husky.neu.edu
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160706/62e8a01b/attachment-0003.html>