[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