Changes to CodeCompletionWorker regarding multithreading

Esben Mose Hansen kde at mosehansen.dk
Tue Jan 18 08:15:14 UTC 2011


On Tuesday 18 January 2011 01:57:46 David Nolden wrote:
> Anyway the whole concept of binary compatibility, even in kdelibs,
> seems superseeded to me. The only applications that profit from binary
> compatibility are closed-source apps. Yes I understand that the idea
> is that KDE becomes an ecosystem for closed- AND open-source apps, but
> the reality after 3 years of KDE4 looks very different, and it doesn't
> make the slightest sense to hinder the development just to help an
> audience which doesn't even exist. For open-source, source
> compatibility is completely enough. When the distribution is using a
> decent build-system, then it makes absolutely no difference for them
> (see opensuse build-service).

Ah, not quite. There are two other cases for ABI-stability. 

There are packagers, which *needs* to have the SO-version correspond to a 
specific ABI. So every time you break ABI, you need to bumb the so number. 
They also worry that having 5 different apps depend on 5 different ABIs for 
one library will lead to excessive memory usage and odd dependency graphs. 

Then there are the library users. They need to be able to say to their 
downstream which version of your library to grab. And they would much prefer 
it if this is a version packed by their downstream's distribution. Constantly 
changing the ABI increases the risk that the version is not there yet/anymore.

Neither of those are closed-source, which in my experience don't really care: 
They just include a copy of all the libraries they need.

I am, on the other hand, right behind you in the sense that kdevplatform could 
use an overhaul to define some nice and clean interfaces. Though that is 
indeed a hard and thankless task :/

-- 
Kind regards, Esben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110118/d04e8a8d/attachment.html>


More information about the KDevelop-devel mailing list