[MPlayer-dev-eng] [RFC] libavutil/x86_cpu.h

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Aug 6 18:05:50 CEST 2010


On Fri, Aug 06, 2010 at 11:42:42AM +0200, Diego Biurrun wrote:
> On Fri, Aug 06, 2010 at 12:01:51AM +0200, Reimar Döffinger wrote:
> > On Thu, Aug 05, 2010 at 11:06:52AM +0200, Diego Biurrun wrote:
> > > On Tue, Aug 03, 2010 at 12:41:46AM +0200, Diego Biurrun wrote:
> > > > We use libavutil/x86_cpu.h all over the place even though it not a
> > > > public header.  This makes building without libavutil in the source
> > > > tree impossible.
> > > > 
> > > > Since this header depends on config.h it will never become a public
> > > > header in FFmpeg.  I suggest that we just copy it to the top level
> > > > of MPlayer.  The header is small and useful and its content are not
> > > > really subject to change; it has been untouched for more than a year.
> > > 
> > > No opinion from anybody?  If I hear nothing I will go ahead once Reimar
> > > is back from vacation in mid-August.
> > 
> > I am not particularly in favour of supporting such a build configuration,
> > also anyone who removes libavutil can still copy that file themselves...
> 
> The reliance on libavutil in the source tree is bad.  It should be
> possible to build without FFmpeg in the source tree and it should
> be possible to build against an external FFmpeg.
> 
> I see nothing to be gained from a reliance on the internals of code
> that is not natively from MPlayer.  This incestuous relationship with
> FFmpeg must eventually come to an end.

But your suggestion does not help anything there, it just changes
the requirement of having a libavutil/x86_cpu.h in the source tree
to instead have a x86_cpu.h in the source tree that we due to SVN's
shortcomings also have to update manually.
That is what it really makes it a no-win.


More information about the MPlayer-dev-eng mailing list