Changes to CodeCompletionWorker regarding multithreading

[Andreas Pakulat]

On 18.01.11 09:15:14, Esben Mose Hansen wrote:
> 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.

In addition to that, packagers will just stop packaging libraries which
change ABI on each minor release if the number of apps using it is large
enough. And large enough actually depends on how many packagers there are
in the distribution caring for kdev and how big the infrastructure is. Sure
SUSE has its buildsystem and other projects have internal distributed
compile farms. But you're wrong that this means ABI doesn't matter to them.

Andreas

-- 
You will become rich and famous unless you don't.