[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...

[Reimar Döffinger]

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.

> > > > 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".
Yes, at some point we should get rid of included libs.
However I don't see a good cost/benefit ratio here.
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.