[packman] RFC: improve MPlayer build in packman

[Carl Eugen Hoyos]

Kshitij Kulshreshtha <kkhere.geo+suse at ...> writes:

> > > Do they explicitly require static
> > > linking with ffmpeg, instead of just using private header files? 
> > 
> > You cannot solve the problem you claim to have (I do not understand it) by
> > including internal headers: They are internal because you must not include
> > them to build a project that uses shared libavcodec.
> 
> Fortunately it is not a problem or a bug. The aim of the patch was to simply
> reduce build load on the pmbs. If packman packagers don't want to use it for
> whatever reasons, that's their choice.
> 
> If internal headers are internal, and you're so opposed to them being included
> in external packages, why have you (you are a mplayer and ffmpeg developer)
> still included them in these filters?

The filters need FFmpeg internals for their purpose: At the time they were
written, no FFmpeg filter layer existed, so they could only be written the way
they are.

> > > If you look into the patch in my last email, you will notice that all
> > > files that were conditioned on defining FFMPEG_A are still built with
> > > this patch using private header-files from the local copy of ffmpeg, but
> > >  ffmpeg itself is not compiled.
> > 
> > So you suggest to provide users with a MPlayer version that is guaranteed to
> > break if they decide to update their libavcodec library? I don't think that
> > would be a good idea.
> 
> If a user uses packman's MPlayer it is almost certain that they're also using
> packmans ffmpeg (libavcodec etc).

(Disclaimer: I don't know much about shared libraries.)
I believe the general idea is that you compile an application against a shared
library, and if you update the library later, you do not have to recompile the
application.
If you build MPlayer with the filters (not) mentioned above, and you update
libavcodec later, you have no guarantee that MPlayer still works because some of
the used functions are not part of the public API.
(I know that one of the negative effects of the traitor's fork is that some API
breaks from the fork are pulled into FFmpeg, and my argument is therefore partly
void, but I currently see no easy solution for this problem. Please report all
regressions you see.)

Note that there is a (very small) performance penalty for using shared
libavcodec, and I believe MPlayer is one of the few applications where you want
to avoid it.

Carl Eugen