On Sat, 25.10.08 12:57, Colin Guthrie (gmane at colin.guthr.ie) wrote: > Hmmmmmm. Heya! > > libpulse requires libpulsecommon but libpulsecommon accesses functions > provided by libpulse.... ? Yes, that is correct. > e.g. pa_xfree is used in libpulsecommon, but it's actually part of > libpulse. ditto for lots of string stuff. Yes, indeed. > Is this deliberate? Is seriously breaks building for me (I can work > around it but it's surely not nice to do this?) Breaks building? how so? But yes, this is intended to be this way. Up to now we were building a lot (and that means really *a lot*) of stuff two or more times: it was built into libpulse AND into libpulsecore (and a lot of other stuff). To avoid this duplication I have now introduced a third library (libpulsecommon) which both libpulse and libpulsecore depend on which includes the common parts. libpulse has a stable API/ABI, neither libpulsecore nor libpulsecommon have that -- they change API every single release. Now libpulse needs to use functions from libpulsecommon and the other way round. After some discussions with a few people (such as Diego) I decided it is probably OK to have this cyclic dependancy on most systems. The dep from libpulse to libpulsecore is explicit. The dep the otherwise round is not -- which is fine because programs will link against libpulse and libpulsecore -- but not exclusively against libpulsecommon. Since libpulsecore also pulls in libpulse it is hence guaranteed that all symbols can be resolved. Why not stick libpulsecommon into libpulse? Because libpulse would then have a partially stable and a partially unstable ABI/API. This cannot be expressed with soname bumps properly and it would be difficult to assure that libpulsecore would always be updated at the same time as libpulse -- to guarantee that their interfacing stays stable. What t do if an arch doesn't like cyclic deps? We'll wait until the problem arises. When it does we have several options: 1) link libpulse statically into libpulsecommon (which would mean duplicate symbols if you link against the real lipulse) 2) do the same as in 1, but replace libpulse by a tiny lib with only weak refs to the real code in libpulsecommon 3) do the same as in 2, but come up with a scheme so that libpulse only conists of short stubs of code that call the real functions. But quite frankly I don't expect this to become a real problem. With this "new world order" we now have zero double compilation. Which makes compilation of PA quite a bit faster. And disk usage quite a bit smaller. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
