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

[Ivan Kalvachev]

On 8/12/14, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
> Hi,
>
> On 12.08.2014 02:21, Ivan Kalvachev wrote:
>> On 8/11/14, Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
>>> 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.
>
> But this path has to come from the pkg-config files.

Yes, pkg-config or programs specificly checking for that path.

>> 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).
>
> But a lot of programs use '#include <libavcodec/avcodec.h>'.

That's problem.
Fortunately we don't have to solve this one right now.

>> 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.
>
> Yes, they still have to conflict.

IMHO, we should do what we can on our 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
>
> Yes, but I patched that out in the Debian package [1], because otherwise
> the programs wouldn't find the pkg-config files.

Oh, this is problem.
IMHO, having the same names is wrong.

Isn't it simpler to have the libavcodec_ffmpeg.pc and a symlink
libavcodec.pc pointing to it?

The idea here is the future.

If program prefers to build with ffmpeg
it should be able to explicitly specify that it wants the ffmpeg
(libavcodec-ffmpeg.pc).

If program doesn't care,
then it uses the generic symlink (libavcodec.pc).

Is there some long debian documentation about symlinks, alernatives,
etc, that you want to avoid? ;)

>> 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.
>
> The problem is that programs only look for libavcodec.pc.

Since Libav breaks API/ABI regularly, all applications require manual
maintenance.
They could change if there is correct alternative.

>> 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?
>
> Probably, that the pkg-config files in the FFmpeg package for Debian are
> still libavcodec.pc etc..

Covered above.

>>>> 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.
>
> I still don't see what the benefit would be, as the *-dev packages still
> have to conflict.

It is the future. If both projects separated headers, libraries and
pkgconfigs, there would be no conflicts.
At the moment we can only change FFmpeg to do the right thing.


>>>> 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.
>
> Except that the programs still should be able to build, ideally with
> both, and which one is used during build is defined by which *-dev
> packages are installed. This is the reason, why the pkg-config file
> names have to be the same.

Ideally, the programs should check for libav and ffmpeg presence and
pick the one they prefer. They do not do that now, because there is no
way to do it.

Let's say that Debian patches Libav configure, so it produces
/usr/include/libav/libavcodec/libavcodec.h
/usr/shared/pkgconfig/libavcodec-libav.pc

The programs that are not ffmpeg/libav aware or simply don't care
would be checking the libavcodec.pc symlink.


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