[FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
ikalvachev at gmail.com
Tue Aug 12 02:21:38 CEST 2014
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
> 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
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
> 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
In short, assuming if Libav doesn't change their library names and
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.
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.
More information about the ffmpeg-devel