python linking hack

simo idra at
Thu Oct 8 07:03:14 MDT 2009

On Thu, 2009-10-08 at 21:52 +1100, tridge at wrote:
> Hi Jelmer,
>  > I might just steal your idea for the short term and then gradually
>  > introduce more smaller libs.
> How many libs are you thinking of? The build times will start to get
> large again if we have dozens of libs, even if they are each small. 

If we can build them in parallel build times shouldn't be a big concern
Also a good makefile will not rebuild each library but only those with
changes I think.

> I also wonder if you are thinking of versioning these libs?
> Maintaining a versioned lib properly is a lot of work, so perhaps it
> would be better using a single unversioned "" just as a
> "shared code" hack rather than doing "proper" libs if doing it
> properly means having the burden of library versioning for lots of
> libs.

As long as these libs are all installed under something
like /usr/lib/samba so that it is clear they are private libs we do not
need versioning.
Versioning is needed once we make them "public" like for talloc, tdb,
tevent, and ldb.
At some point we may need to make some of them more public, like the
libdcerpc stuff openchange needs.

If we want to let people actually start using our stuff there is no
other way. We need to separate the stable stuff from the areas where we
need more development and start stabilizing some of the interfaces.
Splitting the code in multiple libraries helps keeping dependencies
straight and confining "stable" code from "unstable" and changing code.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list