remove internal minilzo (was: Re: [MPlayer-dev-eng] [PATCH] make mplayer's liblzo support compile with lzo 2.x)

[Diego Biurrun]

On Tue, Feb 13, 2007 at 11:19:51AM +0100, Diego Biurrun wrote:
> On Thu, Feb 01, 2007 at 11:29:28AM +0100, Diego Biurrun wrote:
> > On Thu, Feb 01, 2007 at 01:09:41AM +0100, Reimar Döffinger wrote:
> > > On Fri, Jan 26, 2007 at 05:08:20PM +0100, Carl Eugen Hoyos wrote:
> > > > On 2007-01-17 14:29, Bernhard Rosenkraenzer wrote:
> > > > > SSIA -- the patch is about as simple as it can get, given the API is almost 
> > > > > unchanged.
> > > > 
> > > > Unfortunately, Oberhumer decided to change the installation directory for 
> > > > lzo1x.h to .../include/lzo for version 2:  
> > > > http://www.oberhumer.com/opensource/lzo/lzonews.php (Misc), so I don't think 
> > > > your patch will help for typical(?) installations.
> > > > 
> > > > But why keep support for liblzo1? Most libraries are only supported by mplayer 
> > > > if their newest versions are used. What about the attached patch?
> > > 
> > > With latest changes liblzo is no longer used. But ve_nuv.c depends on
> > > our minilzo. IMO it would be preferable to apply the configure part of
> > > this patch, change ve_nuv.c to use liblzo (hopefully someone volunteers,
> > > should be at most 4 lines), and remove minilzo.
> > 
> > That's fine with me.  We should eventually get rid of all the stuff in
> > libmpcodecs/native/ and use FFmpeg instead.
> > 
> > > Requiring liblzo2 for something that is as obscure as I believe ve_nuv
> > > to be is okay IMO...
> > 
> > I just checked, liblzo2 is not bigger than liblzo1, performance is
> > better.  So this should be an acceptable forced upgrade.
> 
> OK, I'm going to commit support for liblzo2 (only) and remove our
> internal minilzo copy.  If you object, raise your voice before the
> weekend, at which point I have planned to commit.

Done.

Diego