Changes to CodeCompletionWorker regarding multithreading

[Jonathan Maasland]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110118/7efc81ac/attachment.html>