Changes to CodeCompletionWorker regarding multithreading

[Aleix Pol]

For now just quanta does and its not released yet.

We should try to get Gluon Creator and PlasMate to use kdevplatform, IMO.

Aleix

On Tue, Jan 18, 2011 at 3:41 PM, Jonathan Maasland
<dreamcatalyst at gmail.com>wrote:

> After reading all the replies I'm left with one burning question:
> Could anyone point me to applications/libraries that depend on the
> KDevPlatform??
>
> With kind regards,
> Jonathan
>
> On Tue, Jan 18, 2011 at 3:08 PM, Esben Mose Hansen <kde at mosehansen.dk>wrote:
>
>>  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
>>
>> --
>>
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>
>>
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110118/c477d3f4/attachment.html>