[pulseaudio-discuss] Master now has circular build dependency

[Lennart Poettering]

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