On Sat, 2009-12-05 at 23:52 +0000, Andrew Church wrote: > >2) Get rid at least partially of our static linking mess and ship > >some of our internal libraries as shared but private. > >See below for an example. > > Not that I've done much of anything recently to warrant my opinion being > considered (: but IMHO this is a Bad Idea, for precisely this reason:
Some opinions are always worth to be heard ;) [...] > >Having the libtc* stuff shared and the tc* programs link to them > >will save a fair number of headaches and annoyances (at least to me). > Out of curiosity, what annoyances have you had with them? I've never > run into any trouble. Well, that's nothing big, but I've got some bad feelings and I've noticed some code smell from a while[1]. Let me elaborate. After some thinking, I've to say that you're probably right and making all the libtc* shared is overshooting. But I still think that making _some_ of them shared it's still a good move. At very least better than we've now. More precisely, it all boils down to - avilib - wavlib - mpeglib (our new recent addition) - libtcutil (the first three are explained below, the fourth one it is needed because the top three uses it to proper integrate with transcode [logging et. al.], and as soon as we move, it's better to avoid backreference and/or circular dependencies). We're fine with, say, libtcexport/video/audio/ext/... as they are now, static, because the thing is straightforward: a program effectively needs a library, so it links it. Easy and nice. Say, tcmodinfo needs to load modules, so it links libtcmodule. transcode needs the same, so it does the same. Fine. But with the above gang of four, the story is different. transcode links avilib(/wavlib/...) not because it needs it, but because _a plugin_ could possibly need it. I think there is something which's needed to be fix when 1) the feature set is first partitioned logically _and phisically_, and the program loads only what he need when he need. 2) the program has to always to pickup something even if it will not use, just in case someone will need it. To put it shortly, should the *avi modules link avilib, not the core. The same way we already happily do for libmpeg2, libav*, everything. As far as I know and remember, the way we're doing now -force libavi* and friends to be linked into the core- is due to the fact that 1. we don't want to install libavi into the system lib directory. Fair enough, and that shouldn't change. 2. we can't static link it to every module which needs it (pointless duplication and most important, it just doesn't work) so the only choice left was to embed it into the core. But that's no longer the only choice left. The key point above that no one figured out a way to separate static/shared and public/private: static meant private, shared meant public (talking about libraries). But we can now do shared private libs. (=>> /usr/lib/transcode-$VER/libavi.so) And IMO everything's cleaner. +++ [1] And since I guess we all already get enough of the "Well, it works anyway, it doesn't?" mindframe from outside -or at very least I do-, I think my position should be understandable ;) Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
