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

[Diego Biurrun]

On Tue, Aug 10, 2010 at 04:04:05PM +0200, Reimar Döffinger wrote:
> 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?

This does no damage at all.  The copied header will not be affected by
such a rename, everything will continue to work as it should.  It is
precisely this kind of breakage that my suggested change would avoid,
not introduce.

Of course we would have to add support for the renamed definition to
configure, just as we have to do now, but we would be no worse off
than currently.

Once I finish and commit my changes for handling FFmpeg as a complete
checkout within MPlayer we will from then on be shielded from any
damage that such a rename within FFmpeg might do.  Only if we copy the
header that is.  If we keep using the one within the svn:external we
shall have to keep chasing FFmpeg build system changes.

In summary, I really see no situation where anything can go wrong and
I believe you have somehow misunderstood.  Please correct me if I am
wrong and outline the details of a failing 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*

--ignore-externals is a neat way to test dependencies on internal FFmpeg
symbols, headers, API, whatever.

Diego