GSOC 2015

[Milian Wolff]

On Thursday 28 May 2015 20:23:26 Maciej Poleski wrote:
> Dnia czwartek, 28 maja 2015 15:54:57 piszesz:
> > Again, I'm missing again some context. kdev-clang will stick to clang-c,
> > the libTooling support must be handled somehow separately, e.g. in a
> > separate process/plugin/library, due to the ABI instability of
> > libTooling.
> 
> What does it mean "ABI instability"?
> C++ does not specify ABI. ABI compatibility between modules in some
> libraries like Qt is something like "assisted" coincidence, result of
> thoroughly implemented changes from version to version of library which can
> free user from need of recompilation on every update of any dependency. But
> in general we cannot guarantee this.
> 
> libTooling ABI is not stable (similarly to ABI of many other libraries), but
> Clang libraries are not DSO (shared libraries). These are in fact archives
> of object code. This code is (statically) linked into binary by the time of
> compilation. Even update of Clang shouldn't break already built code.
> 
> That's why i don't understand why "libTooling must be handled separately...
> due to the ABI instability". Can You elaborate more on this?

Ah, so libTooling can only be linked statically? Interesting! No ABI issues 
arise then. I was expecting the libraries to be installed as shared libs, but 
indeed that is not the case.

Anyhow, the API is unstable, i.e. source-incompatible changes may be done, and 
thus we cannot safely use it without hooking ourselves to a certain clang 
version, which is cumbersome - we want to support multiple distros with 
varying clang versions.

So overall, we go back to the initial idea - move tooling into a (collection 
of) executables and call them from kdev-clang as required. If no executables 
could be build (due to source incompatibilities), then the refactoring actions 
are disabled.

Sounds good?

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150529/d62b7322/attachment.sig>