On Tue, 2005-03-08 at 12:16 -0600, Bob Jamison wrote:
As another example, it looks like Mozilla is carrying their own copy of Cairo now. It is in the CVS tree at mozilla/gfx/cairo.
Considering that Cairo is going to be going through a rather dramatic API shake-up sometime relatively soon, I hope that this is just a measure to keep Mozilla with SVG support building for now. I'd really hope that they take that out again later on. Especially for something which is supposed to be as generically useful as Cairo (lots of people in the X and GTK worlds are planning to make Cairo into the default display and print rendering system) it would be a shame if all apps waste memory by carrying around their own statically linked copies.
For something like potrace, which is unlikely to be in use by a whole lot of other stuff at the same time, and where Inkscape integration has grown to a significant part of the point of the library, including it and linking statically is a whole lot less bad.
Personally I think that the libcroco case sounds like it's somewhere in between. Librsvg depends on libcroco (as far as I can tell, at least that's what RPM tells me on my machine) so it's very likely that it's already installed for most users and thus not a big deal as a build dep. If you include it in the tree, please do make sure that it's possible to link dynamically to an external copy, if at all possible. Given that sort of random stuff is going to get tossed toward libcroco it can be considered somewhat security sensitive (re buffer overflows etc); that makes a shared librar convenient since it only needs a single update in order to fix a newly discovered security problem instead of fixes in all the apps that depend on it. Remember, by pulling something external into the tree, you're to some extent taking on responsibility for bugs (even security bugs!) in that code.
Cheers, Per