kdelibs (tier1) splitting package/repository granularity

Mon May 14 19:43:06 UTC 2012

On Monday 14 May 2012, Kevin Ottens wrote:
> On Friday 11 May 2012 22:55:37 Alexander Neundorf wrote:
> > I mean, I'm all for modularisation, making it easier to use parts of
> > kdelibs instead of the whole thing.
> > But is it really necessary to split each tiny lib into their own
> > repository ?
> 
> Well, obviously I think it is for consistency and future proofing.
> 
> > > Well, that's *today* situation. We know how it works really, introduce
> > > a lib and it'll likely grow overtime. Put a set of libs in a common
> > > repo, and it'll be veeery tempting to sneak a dep here or there. Can't
> > > harm right? :-)
> > 
> > I'd go so far that maintaining the buildsystem of a repository containing
> > 10 libraries (and watching out they don't introduce dependencies) may be
> > easier than maintaining 10 separete buildsystems.
> > At least it's not a clear cut.
> 
> Sure it's not a clear cut like any trade-off. Depends what you value most
> really.
> 
> > I counted yesterday on the splitting epics page. According to it, kdelibs
> > will turn into around 30 separate repositories.
> 
> And it'll probably be even more once kdepimlibs and others join the party
> as I expect it to happen.
> 
> > Each of those should have a maintainer.
> 
> We have troubles with that, but that's the intent.
> 
> > But I think we don't assume that the maintainers also maintain their
> > buildsystem, or do we ?
> 
> Just to make sure I'm not making wrong assumptions here, could you briefly
> list me what tasks you have in mind under "maintain their buildsystem"?
> 
> Right now, by default I'd expect maintainers to also maintain their
> buildsystem. *But*, it'll have to be documented what should be in the
> buildsystem and how. We need a clear reference point for framework
> maintainers, otherwise they'll just let it rot in a corner as they did in
> the past.

I really tried since early 2006 to keep the kdelibs buildsystem pretty, a bit 
less kdebase and kdepim(libs), so those could serve as samples. From time to 
time I looked at the other modules of KDE SC, but much less often.

I tried to educate everybody who had a question how to do it properly, even if 
it took me two weeks, while I could have simply fixed it in one or two 
evenings.

I tried to document it properly on techbase, I documented all changes (until 
4.6 or so) between each major releases, I wrote coding style howto, a 
compatibility policy.

I wrote documentation in the cmake wiki.

I blogged about it from time to time.

I'd consider this good enough documentation.

So I actually think I did a quite good job with that...

> Also, it has to be made as simple as possible for the default cases I
> think. I don't think we succeeded at that in the past, but what I've been
> seeing so far in the splitted frameworks is a very good improvement
> already.

I also want to have it simple, but for different people simple can mean 
different things.
For me, it does not mean "require as little code as possible", see the 
"Convenience trap" (http://doc.trolltech.com/qq/qq13-
apis.html#theconveniencetrap ).
For me, it means the buildsystem code should be as easy as possible to 
understand and modify.

For maintaining a buildsystem, I have e.g. to understand how my library will 
be installed, how it will be packaged, on Linux, Windows, OSX. How RPATH 
works. How packages are searched on the different platforms.

We want every library to install a Config.cmake file for itself. A library 
maintainer must be aware of that, he must be aware what information he can put 
into such a file. This is not generic, this depends on what options or 
optional features each specific library has. He also must know how these files 
are searched, to be able to help users of his library.

Currently we do in frameworks
include(ECMQtFramework).

This completely hides what happens.
It is true that this requires very little typing, but it does not at all make 
it easy for the library maintainer to support his library properly.
He doesn't see what's going on. It is unclear how to add information to the 
FooConfig.cmake file which is created by this include() statement, etc.

See the other long thread mostly with Stephen and me about this.
I definitely want to change this so that this stuff is less hidden, and easier 
to understand by the library maintainer (which is not necessarily the same as 
making it less work for a "horizontal" buildsystem maintainer). This will 
require some more code, but it will make it easier for the library maintainer 
to understand and modify what is going on.

My impression from many autotools-based projects is that their buildsystems 
are a lot of copying around from other existing projects, because they contain 
stuff the developers don't understand and so don't want to touch it.

I want to avoid this, and instead of having a convenient function or file 
which does everything, have a sequence of simple and understandable steps.

> > For me, that's a valid argument for putting tier1 or
> > tier1-no-runtime-deps libs into one repository, and by this decrease the
> > number somewhat.
> 
> Sure, as I said previously I see the incentive. As you can see, I'm not
> convinced that this reduction is worth it compared to the value of having
> something consistent accross all modules.
> Not that I wouldn't welcome such work reduction, it's just that the
> percentage will be around 15% roughly.
> 
> Now, trying to think a bit outside of my own mind box, there might be still
> some groupings which could be done while not confusing people over where is
> what:
>  * The tier4 frameworks could all go together, since they share a same
> topic by nature (it's the consistency frameworks), exception there is
> probably the kde*support ones which are better separated;
>  * The k*addons ones could be grouped in a single framework... In fact that
> would make sense somehow, since each of those will contain a small set of
> classes which "augment" Qt with a thin layer of utility classes (they're
> clearly our weak spot here, they could derail in dumping grounds).

That's all I wanted to get, some thinking about whether some sensible grouping 
is possible, instead of simply splitting everything :-)

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120514/ff58ed17/attachment-0001.html>