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

[Diego Biurrun]

On Fri, Aug 06, 2010 at 06:05:50PM +0200, Reimar Döffinger wrote:
> 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.

No updating will be necessary.  FFmpeg will continue to use its own
copy in libavutil/ regardless of whether or not we have it elsewhere.

On the contrary, if libavutil/x86_cpu.h changes, our local code will
not have to be modified because it will continue to use the stable
header under our control.

That said, I do not expect many changes to this header file, much
less changes that might be worth porting over.

Diego