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

[Volker Krause]

On Monday 08 November 2010 19:50:33 Tom Albers wrote:
> > 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?

we have link time dependencies (most common), but also build time only 
dependencies on header-only stuff.

> > 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.

as far as I understand the split layout, you'd need to check out all of them 
individually, which I wouldn't call "simple" ;)

But I still know very little about git myself. Marc suggested it might be 
possible with the use of something like git submodules to come up with a 
hybrid solution which combines the best of both worlds, allowing individually 
and combined checkout/build.

> For third 
> party applications that want to use a certain library, they can easily sort
> out which libs are needed.

sure, for one it's not a problem, just for all of them it get's inconvenient.

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

which is fine imho, as long as it's available for all platforms we support and 
preferably also easily portable to new ones, can be integrated in cross-build 
setups etc.

> > 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.

Well, those external parties would need to check out everything (currently 
even build everything if you don't comment out a few cmake lines of stuff you 
don't need), but not depend on everything.
Our current mobile packages work that way btw (for all of 
kdelibs/pimlibs/pim), we build a lot more than we actually need and just 
package the stuff we really 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.

absolutely

> 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.

I fully agree, and IMHO it's important to discuss our options now that we have 
the chance to change something.

> > 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.

of course I see advantages in the split layout, but also the mentioned 
disadvantages :) I'm still undecided what would be the best solution. Also, 
as mentioned already, I don't know much yet about git so some of my concerns 
might simply be void.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20101109/b9aece90/attachment.sig