[Kde-scm-interest] Re: [Kde-pim] Re: Re: Fwd: KDEPIM Git Move

[Tom Albers]

Hi Volker,

----- Original Message -----
> kdepimlibs has currently about 20+ libs in it, not all of them are
> independent, probably about half of them depend on each other in
> obvious and
> not so obvious ways.

You mean they include headers from eachother with ../../ktnef/bla.h like ways? Or simple this lib depends on that lib constructions?

> IIUC you would need to check out all of them
> individually and then figure out the dependencies manually (something
> that
> cmake currently does for us)?

Well, if you want kdepim, you can simply check them all out. For third party applications that want to use a certain library, they can easily sort out which libs are needed.


> would
> basically
> force the use of a tool such as kdesrc-build to do the job for you.

True.

> While making things more modular is of course a very desireable goal,
> I'm
> wondering if we really need one repo per lib for that? It wont
> magically
> reduce dependencies, and it's not exactly making it easier to use
> single
> libs. To stay with the KIMAP example, you'd need KMime for that, as
> well as
> kpimutils (build time only), three repos instead of one.

If possible you can also combine a few libs of course, but I don't expect that to be easier. The dependencies are per library instead of globally indeed. Which also makes it easier for external parties to use the libraries and not have to depend on all kinds of stuff that they don't need.


> IMHO reducing/clarifiying dependencies, allowing to compile only the
> desired
> sub-sets and advocating split-up packaging could help more than
> individual
> repos. While they make the dependencies more obvious (and thus
> hopefully make
> you think twice before adding a new one), they come with a
> considerable price
> it seems.

Yes, that's true. The part you put between () is important though.
But this is one of the moments that you can do it. If you let this oppertunity go, it will be pretty difficult to do it later imho.
 
> How is this handled in kdelibs btw? I guess following whatever is done
> there
> makes most sense, so things are consistent in the main KDE repos.

kdelibs is not converting to git yet, and is quite different in layout imho, since kdelibs has less clear splittable parts. A solution there with cmake is on its way as you know, but I think everyone agrees it should not be one big monolitic piece of code. I think this is a chance for kdepimlibs to set an example.

But if you don't see the advantages or think it is too inconvenient to have all those git repo's (which I can imagen), then it should not happen. It's just an idea.

Best,
-- 
Tom Albers