KDE/kdelibs

[Ian Wadham]

On Thursday 26 November 2009 8:05:07 pm Tom Albers wrote:
> I've seen once a document, I think from Allen Winter, which outlined how we
>  could handle new dependencies. Unfortunately I can not find it anymore,
>  but I thought it was a good proposal. I suggest we - The Collective - find
>  that document and accept it as a guideline for these things.... (just mho).
> 
Thanks, Tom, that would be really nice!

It's not just new dependencies but changes in dependencies and even
some existing long-standing dependencies that impede one's work when
one has an app which is distant from the core of KDE and the desktop.

As an example of a long-standing dependency, everyone who wants to develop
and test with the latest kdelibs has to build kdepimlibs.  Why?  What is the
relevance of kdepimlibs outside its own functional area of Kontact, etc?  That
dependency in turn has sent me hunting, in the last month or two for newer
versions of "boost" and "libical".

"Boost" has these weird build instructions and I kept getting errors from
the build, but eventually I found I had built enough of it to satisfy KDE
dependencies.  Well and good, but not very confidence-building.  It
felt a bit like taking off in a light plane when you know there is a loose
bolt in the engine compartment somewhere.

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.

It's like that butterfly here in Australia that flaps its wings and sometime
later there is a hurricane in New York.  Several hours after starting to
build I may get to see what that cool game-feature was.

In an ideal world, I would like to see a straight line of dependence from
my app (or any other non-core app) to kdelibs to Qt.  Maybe we could
just separate out the parts of kdelibs that the majority of applications
frequently use.  Something like that might also make kdelibs easier
to install and use in non-Linux or non-KDE environments.

All the best, Ian W.