On Wed, 13 Feb 2008, Glynn Clements wrote:
[...]
The same reasoning applies to MySQL, PostgreSQL etc. Whether to use
"#include <directory/file.h>" or to use "#include <file.h>" along with
-I/path/to/directory is a property of
how the headers are meant to be used,
^^^^^^^^^^^^^^^^^^^^
I didn't realise how easy it was to check this (i.e.
looking to see how the headers include "sibling" headers) nor how
important it was. I do now, quite interesting. I would still consider it
an annoyance though.
not where they happen to be installed.
E.g. OpenGL headers are supposed to be included as <GL/gl.h>, X11
headers as <X11/Xlib.h>, Athena headers as <X11/Xaw/Text.h>, etc;
anything else (i.e. moving the prefix to the end of a -I switch) is
incorrect.
Any -I switches are determined according to the installation path
*after* you have determined the correct #include directive.
If a package is designed so that headers are included without any
prefix directory, yet installs them into a package-specific
subdirectory, the intention is that the headers will not be found
without a specific -I switch.
BTW:
$ pkg-config --cflags libavcodec
-I/usr/include/ffmpeg
Ditto for libavformat and libavutil.
Also, visualization/nviz/src/Makefile includes references to
FFMPEGINCPATH, FFMPEGLIBPATH and FFMPEGLIB but as far as I can see none of
the C files in that directory use any FFmpeg functions - can it be
removed? (I'm going to test it and see if anything goes wrong...)
In this case, I think that it can be removed, as none of the OGSF
headers appear to include the FFMPEG headers.
OK, I've done that.
Paul
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
