Applications and bundled libraries
Posted Mar 18, 2010 3:59 UTC (Thu) by blitzkrieg3
In reply to: Applications and bundled libraries
Parent article: Applications and bundled libraries
Keep in mind that we build on Windows, so much of the code in our
third_party directory is there because we need that code on Windows.
There are a number of configure time flags to switch between the
third_party and system versions of libraries like zlib, libevent etc.
No one is decrying your use of a third_party directory. Mozilla does this too.
However, it's a bit harder to use system libraries than you make it seem. For example, looking through spot's src.rpm, I see no less than 7 patches to hardcode stuff to use system libs. Take this commit for example. Pretty much every file references ../third_party/icu, but when you look for the actual directory, it isn't there!
Having said that we do have a number of forks. Here's an unrepresentative
selection of them covering some of the reasons:
libevent: we needed bug fixes and we needed to be able to run on systems
which didn't have them.
icu: we need a more recent version than was even provided on Karmic.
These are the distributors problem. Either they configure --with-system-libevent and get the libevent maintainer to update their part or build and ship with the library.
libjingle: upstream appears to be unmaintained.
Several have mentioned Google is the upstream maintainer. Either whip the talk guys into shape or get commit access to their tree.
sqlite: we added full-text indexing (now upstream) and several performance
improvements which are rather specific to our use case. We don't want to do
without them and upstream aren't too interested.
This sounds like an excuse.
I don't think that Mozilla is that much better, and spot is incorrect that they don't bundle libraries (--with-system-png is commented out in F13 alpha and I know mozilla has their own brand of cairo), but with a few changes we can duplicate less work and simultaneously get a better product
to post comments)