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