Changes to CodeCompletionWorker regarding multithreading

[Esben Mose Hansen]

On Tuesday 18 January 2011 14:31:23 David Nolden wrote:
> Both of these points seem like they could be fixed by changed
> workflows on the packager/distribution side (packers wouldn't need to
> do more work, they would just need to have the right tools), and not
> like general arguments for binary compatibility.
> 
> The fact that packagers don't seem to have the right tools makes this
> a purely philosophical discussion though.

How, exactly? Every time a library changes its ABI, you have 2 choices: 

1. Rebuild /all/ packages that uses the library 
2. Have 2 versions of the same package with different ABIs. (e.g. 4.2.0 and 
4.2.1)

Otherwise, those depending packages *will* break, and not in a pretty way.

The first is just not possible, unless all your packages comes from one single 
source, with no custom repositories, as it would require perfect coordination 
between those repositories. It would also mean that one small library change 
could cause the user to download 100s or even 1000s of packages (for fun, 
imagine libstdc++ or glibc having a ABI change.)

The 2nd is doable (see libboost), but leads to a pletora of dependencies on 
various versions of a package. As a (downstream) user, I am thankful that 
boost is the exception, rather than the rule. If we wanted to go this way, it 
is also *critical* that we informs our packagers that this is the road we are 
taking, so that they can add the proper conflicts and depends to their 
packages.

All this is of course ignoring the bit I said about users, who needs to be 
able to point to a specific version of the library, preferably one that is 
packaged by distributors.

In conclusion, I fear ABI stability is something we have to live with if 
kdevplatform is ever to be regarded as a proper library. As long as we only 
have a few users, changing every 4.x release is fine, though. It's not like 
someone would grab a new version of kdevplatform without rebuilding kdevelop 
and the php-ditto, too.

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