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

[Andreas Cadhalpun]

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.

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

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

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

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

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

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

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

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

1: 
https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/tree/debian/patches/pkg-config_file_without_build_suffix.patch