Separating everything ?

[Frank Reininghaus]

Hi,

2013/2/6 Alexander Neundorf:
> Hi,
>
> at Kevin's talk about KDE frameworks at FOSDEM last weekend, one guy from the
> audience asked why he should not use all KDE libs if he decides to use one
> already...
>
> This got me thinking.
> Obviously, dragging in everything is what we want to avoid.
> Making kdelibs modular should also make building the libs easier. I mean, if
> I'm a developer under Windows and want to use only karchive, I "only" have to
> make sure zlib, bzip and lzma can be found, and I'm fine to go.
> Orders of magnitude better than before, where I would have had to make sure
> enough from kdesupport can be found so I can start building kdelibs, including
> strigi, nepomuk, etc.
>
> Still... the tier1 libraries will not have any interdependencies.
> Especially the tier1 functional libs.
> And they are partly really tiny.
>
> If they don't have any interdependencies, it is trivial to add a cmake switch
> for each of them, so if I want only karchive, I simply disable all others.
> Qxt does it similar IIRC.
>
> Kevin actually suggested that breaking it into too many very small packages
> would indeed be quite some work for packagers.
>
> So, what do I suggest ?
> Let's put all tier1 function libs into one repository and package, making it a
> bit easier for the packagers (and also for developers, who have to deal with
> maybe 10 to 20 repositories less).

This may be a stupid question, but what is actually the benefit that
we get from splitting the kdelibs repository into multple
repositories? I mean, putting all frameworks into a nice directory
structure and making it possible to build and release them separately
is very nice, of course, but why put them into different repositories?

I would say that the current KDE 4 situation, where not only kdelibs,
but also kactivities and 2 different Nepomuk repositories are more or
less hard dependencies for building most other KDE packages in a
useful way already causes quite a bit of trouble in some situations.
It will get worse if kdelibs is split into different repositories.

The problem that I see is not only that every KDE developer has to
clone lots of different repositories and keep them updated - this can
be automated using scripts such as kdesrc-build. What I have in mind
is also situations where you don't know in which part of KDE the cause
of a recent regression is located. You would have to state the SHA1
hash of every repository when you discuss the issue with someone, and
git bisect becomes essentially useless if you have to do it in many
repositories. And this is probably not the only inconvenience that a
"multiple repositories" approach would bring for people who want all
of KDE frameworks anyway. Therefore, I think that having the basic
requirements for building KDE apps in one repository is a good thing
that should not be sacrificed unless there is a very good reason to do
it.

Is there anything obvious that I'm overlooking? One could argue that
separate repositories make it easier for non-KDE people to contribute
to one particular framework. But if each framework inside the kdelibs
repository can easily be built separately, this point looks moot to
me, and it cannot justify making the build and debug process more
painful for the (probably rather common) case that a person wants to
build and use all of KDE frameworks.

Cheers,
Frank