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

[compn]

On Mon, 12 Sep 2011 18:23:36 +0200, Diego Biurrun wrote:
>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.

i've never gotten autotools working on mingw/cygwin.
whereas mplayer compiles with minimal mingw hacking.

not a good reason for keeping a lib, just another straw.

-compn