[MPlayer-cvslog] r34099 - in trunk/libass: ass.c ass.h ass_bitmap.c ass_bitmap.h ass_cache.c ass_cache.h ass_drawing.c ass_font.c ass_font.h ass_fontconfig.c ass_fontconfig.h ass_library.c ass_library.h ass_parse.c...

[Diego Biurrun]

On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar Döffinger wrote:
> On Mon, Sep 12, 2011 at 10:50:49AM +0200, Diego Biurrun wrote:
> > On Sun, Sep 11, 2011 at 10:34:17PM +0200, Alexander Strasser wrote:
> > > Diego Biurrun wrote:
> > > > On Sun, Sep 11, 2011 at 02:05:20PM +0200, Reimar Döffinger wrote:
> > > > > On Sun, Sep 11, 2011 at 01:47:57PM +0200, Diego Biurrun wrote:
> > > > > > On Sun, Sep 11, 2011 at 12:33:14PM +0200, reimar wrote:
> > > > > > > 
> > > > > > > Log:
> > > > > > > Update included libass copy to 0.9.13 release.
> > > > > > 
> > > > > > What's the point of continuing to carry this lib around?  AFAIR it is now
> > > > > > widely available in distributions, so IMO we should just check at configure
> > > > > > time and use the system library.
> > > > > 
> > > > > Neither Windows nor OSX include it.
> > > > 
> > > > And who of these people compiles from source?  Those that do can compile
> > > > libass, what's the problem?  Do we bundle libc?
> 
> I am one of those people occasionally and I haven't tested whether I can
> compile libass.
> So far keeping the copy and updating it seems the minimal effort method.

But that does not help libass, so try and report bugs to them in the
unlikely case that it really does not work :)

> > > > > And to my knowledge e.g. Gentoo is still defaulting to a setup that ends
> > > > > up combining the crashing library versions.
> > > > 
> > > > There will always be some combination of distro and lib version that is
> > > > buggy.  Report bugs, get them fixed, don't accumulate local workarounds.
> > > 
> > >   Please keep up the flames. This exactly the wrong way and IMHO the
> > > wrong mailing list to start such a discussion.
> > 
> > If you wish to move the discussion to dev-eng, go right ahead.  However,
> > everybody is subscribed here, so it's as good a place as any to discuss.
> > 
> > Reimar and I have talked about this in the past, the last time the decision
> > was to postpone a decision about libass because it was not yet widely
> > available in distros.  This is no longer the case.
> 
> Actually it was rather "a properly working version available in
> distros", which as I mentioned is still problematic.
> There's also other things like it using autotools without the generated
> scripts being checked in, which I still see as big advertisement of
> "you won't manage to get it to build on half of your systems".

Ummm, where?  In dist tarballs or the git tree?  They should definitely
not be in the git tree.  I have not seen "autoreconf -i -f" fail in a
long time.  If it does, I will fix libass.

> Yes, at some point we should get rid of included libs.
> However I don't see a good cost/benefit ratio here.

I don't see it either, but the other way around :)

> If we want to remove things: Does anyone remember a reason to keep
> mp3lib? Because that one is high-cost in comparison.
> We have some custom changes there, but they seem like they start to
> become a negative value, mpg123 and mad both seem to be better, and
> ffmp3 is the included alternative.

I'm all for it, someone go and prepare a patch.

Diego