kdelibs (tier1) splitting package/repository granularity

[Alexander Neundorf]

On Monday 14 May 2012, Kevin Ottens wrote:
> On Monday 14 May 2012 21:43:06 Alexander Neundorf wrote:
> > On Monday 14 May 2012, Kevin Ottens wrote:
> > > 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...
> 
> Sorry, I didn't mean you did a bad job in the past. Just pointing out that
> the thing already looks very different from what we had in the past, and
> so... the documenting effort will have to be pretty much redone. That's
> necessary (but obviously not sufficient...) step if we want to get a
> chance to have maintainers maintaining the buildsystem of their framework.

Yes.
One of the things I'd like to do quite soon is put an example into the 
kdeexample/buildsystem/ directory for how to install a library using cmake 
2.8.8 (the example which is already there uses cmake 2.6 features).
 
> > [...]
> > 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.
> 
> I hope you succeed. The challenge though is that there's nothing like an
> "apidox for build". 

http://api.kde.org/cmake/modules.html :-)

...
> > That's all I wanted to get, some thinking about whether some sensible
> > grouping is possible, instead of simply splitting everything :-)
> 
> *sigh* Of course we never put any thinking before right?
> 
> "splitting everything" can't be further from the work which has been going
> on so far (nor the ideas jotted at Platform11). When it makes sense we
> group (see kconfig for instance as latest incarnation of that...). We're
> not aiming at one lib per repo, we're aiming at one framework per repo...
> and yes sometimes it'll be a single tiny lib if it can't be grouped with
> something else. For some cases it's easier to find the right groups than
> others, the k*addons (potential) group I gave earlier is stretching a bit
> IMO, but that's an option.

That's good :-)
You know, when I got the answer that every library in tier1/ and tier2/ is 
supposed to be moved into a separate repository this did not sound as what you 
describe.

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