[FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
andreas.cadhalpun at googlemail.com
Tue Aug 12 20:48:13 CEST 2014
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
>> 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
Yes, but I patched that out in the Debian package , 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.
More information about the ffmpeg-devel