[FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory

[Ivan Kalvachev]

On 8/11/14, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
> Hi Ivan,
>
> On 11.08.2014 01:23, Ivan Kalvachev wrote:
>> The patch is inspired by something I read in the Debian discussion.
>> Libav and FFmpeg could be installed side by side without conflicts in
>> the libraries, thanks to using additional suffixes.
>
> Thanks for your interest in the matter.
>
>> However development/include files are still conflicting, so I thought
>> of a simple configure hack to give more control to FFmpeg.
>>
>> With this patch you can do `./configure --extra-incdir="/ffmpeg" --prefix="/usr"` ,
>> as result the header files would be installed in
>> "/usr/include/ffmpeg"
>> e.g.
>> "/usr/include/ffmpeg/libavcodec/avcodec.h"
>> ...
>
> Assuming it would be possible to install development packages for both
> at the same time, which one should be used, when building a program?

It would be decided by the gcc -I inclusion option.
It modifies the search paths for header files, so that it checks these
paths before the system/default ones (When using `#include
"libavcodec/avcodec.h" `)

Libav headers are probably going to remain in the default /usr/include/ .
Usually this should not be a problem, unless a program uses `#include
<libavcodec/avcodec.h> ` that should be used for system headers (aka
checks the system/default paths first).


There might still be problems if there are explicit -I/usr/include
inserted by other libraries that mix the inclusion order.

To avoid hard to debug compiling problems, that the -dev packages may
still be marked as conflicting, even though no files are overwritten.

This final conflict however cannot be resolved on FFmpeg side.

>> The change is reflected in the pkgconfig files too. Since applications
>> that link to libraries with addition suffixes should be using
>> pkgconfig, they would be using the correct header includes
>> automatically.
>
> If that's to be determined via pkg-config files, then the obvious
> problem is that both install these files in the same location, and if
> one doesn't, programs can't find the library.

The problem is not that they are installed in the same location, but
that they have same names.

However I just checked and when you define library suffix (e.g.
--build-suffix="_ffmpeg"), it also adds the same suffix to the .pc
files. So you have
/usr/lib/share/pkgconfig/libavcodec_ffmpeg.pc
/usr/lib/libavcodec_ffmpeg.so

In short, assuming if Libav doesn't change their library names and
pkgconfig files,
the programs that are looking for 'libavcodec.pc'  would get the Libav one,
the programs that are looking for 'libavcodec_ffmpeg.pc' would get FFmpeg.

I believe that you should already be using --build-suffix, so that
should already be in the package.

Is there something else I'm missing?

>> I did just a rudimentary test and I couldn't spot anything wrong.
>> Please test it before inclusion.
>
> The patch seems to be alright, but it doesn't make it possible to make
> the development packages of FFmpeg and Libav co-installable.

Unfortunately not.
But without the patch the problem is entirely in how FFmpeg installs its header.
With it, it is entirely Libav problem for using system/common
directory. Then, if Debian wants to resolve the conflict, Libav header
files could be moved in their own directory. The patch should be
trivial to port.

>> As for the future, it might be good idea next major release (e.g. 3.0)
>> to have the $prefix/include/ffmpeg as default include path (for
>> non-comapt build).
>
> So this would also not help.

At the moment FFmpeg is trying to mimic 100% Libav API/ABI, and to be
perfect drop-in replacement. This means using the same library names,
locations and header files.
This is what I call compat build. It is 100% compatible with Libav
from application/program point of view.

When using --build-suffix, you obviously want to differentiate from
Libav, so I call that non-compat build.

Sorry if this is caused confusion.

I hope that the way Debian packages FFmpeg would actually turn out to
be the new default.

Best Regards
   Ivan Kalvachev
  iive