[MPlayer-dev-eng] [RFC] libavutil/x86_cpu.h
diego at biurrun.de
Fri Aug 6 18:21:29 CEST 2010
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.
More information about the MPlayer-dev-eng