Tagging kdesupport projects

[Andreas Pakulat]

On 01.09.08 14:45:23, Sebastian Trüg wrote:
> On Monday 01 September 2008 14:15:42 Harri Porten wrote:
> > On Mon, 1 Sep 2008, Sebastian Trüg wrote:
> > > Actually, no. At least I still do not get it. The way I understand it is
> > > this: Whenever there is a KDE release, be it alpha, beta, or final, we
> > > need a Soprano release as a dependency. So far this has always been the
> > > case. KDE 4.0 uses Soprano 2.0 (but can also use 2.1 since its BC), 4.1
> > > is based on Soprano 2.1 (currently 2.1.1 is the latest stable release,
> > > check soprano.sf.net), and 4.2 will be based on Soprano 2.2 (currently
> > > developed in trunk).
> > > But I don't see why we need a release "just" to build trunk. Thrunk
> > > changes all the time. I have no intention of building snapshots myself
> > > all the time. I have no problem with an automated system for that though.
> > > ;)
> > > So, if you want to create a KDE release you will of course get a Soprano
> > > release, too. But before that.... why?
> >
> > Because its a pain for all developers working on trunk. One never knows
> > whether all of kdesupport needs to be updated and re-build too. And which
> > branch to use for that.
> >
> > In order to not constantly break things for other developers a developer
> > of non-KDE and KDE relying on it should
> >
> > * Version the non-KDE code in a way that it's clear to developers of KDE
> > code that a requirement is not met.
> >
> > * In the intermediate phase develop the KDE code in a development branch
> >
> > * Or simply put all of it into the main KDE modules.
> >
> > I have to say that I find the tendency to move hard-requirement libraries
> > (targetted at KDE mostly) into kdesupport a bit disturbing. It could have
> > been done with KJS too (its only requirements are libstdc++, libstdc and
> > pcre) but I found it counter-productive. Instead I favor development
> > within KDE. Seperate packages for non-KDE use can always be produced.
> >
> > Harri.
> 
> I don't get the problem. It is so simple: on mondays it is possible that stuff 
> breaks. thus, when it does, simply update kdesupport to trunk and keep on. 
> You need to do the exact same thing with kdelibs. There are no multiple 
> branches you need to choose from. There is trunk for bleeding edge developers 
> and there are the releases in case you are an app developer who "only" needs 
> KDE 4.0 or 4.1. There is absolutely nothing complicated about that. If you 
> can compile kdelibs, you can also compile kdesupport, it is much smaller.

I'm with Sebastian here, I've always built kdesupport from trunk and
I've seen far less problems with those parts than any other module I
build from trunk. If its time-consuming for anybody to build kdesupport
he/she doesn't use the right tools to do it. Personally I'm using
kdesvn-build, but basically any fire-and-forget bash script that just
iterates over the dirs, svn up's and re-runs make should do. And thats
something you can issue before having your dinner and its finished when
you get back. I'm never actually building anything except parts of
kdevelop when I'm hacking. Any other updates need to wait until I get to
bed or get up next morning - so building is done when I don't need the
machine.

As far as knowing which version of a kdesupport library is needed for
KDE 4.x (where x is a released version), this should already be enforced
properly by our build-scripts - if not thats an error in those CMake
files. Obviously a human readable list would be nice to know before
starting the compile process.

Andreas

-- 
If your life was a horse, you'd have to shoot it.