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

[Reimar Döffinger]

On Tue, Aug 10, 2010 at 01:29:44PM +0200, Diego Biurrun wrote:
> > And right now, only if we change configure to generate two defines for the
> > same thing if FFmpeg renames then
> > And even that only works if FFmpeg does not use those old names for something
> > else.
> 
> The ARCH_ #defines are also used in MPlayer in various places, they will
> not go away.
> 
> We seem to be misunderstanding each other.  Could you please give an
> example where anything can go wrong?  I cannot see how copying that
> header can introduce problems, ever.

HAVE_EBX_AVAILABLE being renamed, for example?

> > What is the point?
> > If someone removes libavutil they'll hardly break their fingers
> > by in addition copying that x86_cpu.h file, why do we have
> > to do that for them?
> 
> svn checkout --ignore-externals
> 
> is a configuration that we should make an effort to support.  It is a
> useful and sensible thing to do, Nico works that way and I would like
> to do it as well.  It really does marvels to compilation speed.

Then you _once!_ copy the x86_cpu.h file to libavutil/ and be done.
Also I really fail to see how --ignore-externals would change
compilation speed, except it being a lazy way of disabling the
internal libav*

> Nico kept complaining to me that you undermined all his efforts to
> have MPlayer work without embedded FFmpeg and I promised to help
> improve the situation :)

That's a joke, I think I have done more than most, if not all others,
to make it work, despite not even caring about it or using it.
Yes, some parts on libavutil are still an issue, but copying parts,
particularly parts that make a lot of sense to be shared (e.g.
x86_cpu.h is used by many filters, some of which exist both
in libmpcodecs and libavfilter) at best hides issues.