[GRASS-dev] FFmpeg include files location

I've only ever compiled and installed FFmpeg myself, but it always puts its headers into ${PREFIX}/ffmpeg. Hence, when a C file includes these headers it should do e.g. #include <ffmpeg/avformat.h>. However lib/ogsf/gsd_img_mpeg.c includes files directly without the ffmpeg/ prefix. Is this valid on any common Linux distributions - are the FFmpeg header files directly in /usr/include instead of /usr/include/ffmpeg? If not, I think we should change it and the configure check so they work properly, i.e. no special value is required to be given for --with-ffmpeg-includes if they've been installed in the standard location.

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...)

Paul

On Wed, 13 Feb 2008, Paul Kelly wrote:

I've only ever compiled and installed FFmpeg myself, but it always puts its headers into ${PREFIX}/ffmpeg. Hence, when a C file includes these headers it should do e.g. #include <ffmpeg/avformat.h>. However lib/ogsf/gsd_img_mpeg.c includes files directly without the ffmpeg/ prefix. Is this valid on any common Linux distributions - are the FFmpeg header files directly in /usr/include instead of /usr/include/ffmpeg? If not, I think we should change it and the configure check so they work properly, i.e. no special value is required to be given for --with-ffmpeg-includes if they've been installed in the standard location.

Looks like a similar thing could be said for MySQL include files and db/drivers/mysql/globals.h. I'm almost sure there was a discussion about something like this with PostgreSQL a few years ago - but in that case IIRC it was PostgreSQL's naming convention, rather than GRASS that was broken.

Paul

Paul Kelly wrote:

I've only ever compiled and installed FFmpeg myself, but it always puts
its headers into ${PREFIX}/ffmpeg. Hence, when a C file includes these
headers it should do e.g. #include <ffmpeg/avformat.h>.

Nope.

If you look at the top of the aforementioned avcodec.h, you will see:

  #include "avcodec.h"

In order for this directive to work, you have to compile with e.g.
-I/usr/include/ffmpeg.

However
lib/ogsf/gsd_img_mpeg.c includes files directly without the ffmpeg/
prefix.

That's correct.

Is this valid on any common Linux distributions

It's the correct way to include FFMPEG headers on all platforms.

- are the FFmpeg
header files directly in /usr/include instead of /usr/include/ffmpeg?

No, they're usually in /usr/include/ffmpeg.

If
not, I think we should change it and the configure check so they work
properly, i.e. no special value is required to be given for
--with-ffmpeg-includes if they've been installed in the standard location.

No, you have to specify the directory if the headers are put in their
own subdirectory.

To be precise, you *must* have a -I switch so that the "internal"
#include directives work. It's established policy to give the user
complete control over which -I or -L switches are used; configure
never adds directories of its own accord.

[We used to try to autodetect directories. It often broke stuff due to
pulling in directories containing incompatible headers (e.g.
incompatibilities between vendor-supplied packages and GNU packages on
commercial Unices), and there was no way to get around it.]

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, 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.

--
Glynn Clements <glynn@gclements.plus.com>

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