KDE/kdelibs

[Ian Wadham]

On Thursday 26 November 2009 10:57:52 pm Andreas Pakulat wrote:
> On 26.11.09 22:33:44, Ian Wadham wrote:
> > As an example of a long-standing dependency, everyone who wants to
> > develop and test with the latest kdelibs has to build kdepimlibs.  Why?
> 
> kdelibs cannot depend on kdepimlibs, the opposite is true obviously
>
I follow http://techbase.kde.org/Getting_Started/Build/KDE4 and yes,
I was in error, but half right.

It's kdebase that depends on kdepimlibs.  But the writeup says that
kdebase/runtime is "a required dependency for each KDE application,
so you have to compile and install this".  So even if all you want is kdelibs,
you have to build kdepimlibs and part of kdebase.  I think you still have to
build kdesupport too, but I am not sure of that, so I play safe and build
it anyway.

> > "Boost" has these weird build instructions and I kept getting errors from
> > the build, <snip>
> Why are you compiling boost in the first place? Last I checked kdepimlibs
> also works with "old" boost versions (1.37 was the oldest I tried
> recently), so just take packages from your distro for that.
> 
Because, until a week or two ago (SuSE 11.2 release, with KDE 4.3.1) I was
unable to get a KDE 4 desktop to work on my laptop.  I had been trying since
before KDE 4.0 release, nearly 2 years ago now.

> > Then again, I would like to have a hot dinner for every time somebody
> > on the KDE Games list writes about some cool new feature in his game,
> > so I go and try to update and compile it.  However one of the other games
> > is now referencing a method that has just been added to kdelibs or Qt.
> > Then when I build kdelibs, I find something has changed in Strigi or
> > Akonadi or whatever ... and on and on, as Kurt Vonnegut used to say.
> 
> Thats what happens if you run trunk. If you don't want that, don't use
> trunk. Sorry, but either you want "the latest greatest breakage" and hence
> have to care yourself for changed dependencies and following the
> development of the dependencies you want to build from trunk. Or you take
> the stable release and can't see up-to-date features until the next
> release.
> 
That is out of the question.  It is not that I want/need the latest greatest.
I'd be very happy to base my games for v4.4 release on v4.3 libraries,
but that would be both unwise and currently impossible.

Unwise because games, especially my game, often throw up bugs,
regressions and inefficiencies in KDE and Qt libs, which we then have to
get fixed or program our way around.  It would be foolish of us to test
KDE games against an old release of the libs and then release them
with the latest greatest.

Currently impossible because we have all been told to use Qt 4.6, git and all 
that for the KDE 4.4 release.  It's in the KDE 4.4 schedule.

> The only way to change that, is talk to your module coordinator and
> establish a rule in your module that it must be compilable and work with
> the current stable release of kdelibs&co. Of course that also means having
> to wait another 6 months before being able to use the newest features from
> kdelibs.
> 
Sometimes we really *need* the new stuff and sometimes not.  KDE Games
can be quite cutting-edge at times and we have done a lot of involuntary
"testing" of both Qt 4 and KDE 4 in the last 3 years or so.  I have the scars
and grey hair to prove it ... :-)

All the best, Ian W.