GSOC 2015

[Milian Wolff]

On Saturday 30 May 2015 11:23:33 Maciej Poleski wrote:
> Dnia piątek, 29 maja 2015 17:55:47 Alexander Richardson pisze:
> > That depends on how the distro decides to ship the clang libs.
> > I have /usr/lib64/libclangTooling.so and
> > /usr/lib64/libclangToolingCore.so on my openSuSE system.
> > 
> > Alex
> 
> Right (It's a bit strange as all LLVM/Clang example Makefiles link with
> static versions). I Was looking at my Gentoo system which has only static
> libraries in this package. But still I'm missing something. In general any
> update to shared library may break ABI (break packages which depend on this
> library). Linux distributions must handle this somehow. In openSuSE (which
> I use to send this message) is package "kdevelop5-plugin-clang". If update
> to (some package here, ex. LLVM) break ABI, then distro should rebuild all
> packages that depend on this updated package and bump their versions to
> ship new binaries as update with update to base package. That's how I
> imagine this. On Gentoo it is slightly different because upstream ships
> only source code and task of rebuilding is on portage or (if it's not
> enough) on system administrator. And it's not uncommon to break some
> packages during system upgrade...

You have some things wrong here:

a) ABI/API breakages in libraries are usually frowned upon
b) they are not common at all, only a few exceptional libraries don't care 
about it (most notably boost)
c) packagers hate it when they have to rebuild stuff only because the abi 
changed in a library
d) there are rolling release distros, similar to gentoo, but without the 
compilation overhead. you don't want to break stuff just because your user 
updated a dependency.

Due to that, KDE Frameworks and Qt for example impose strict rules to prevent 
API/ABI breakages. Clang and LLVM are still in flux, which is why they do not 
give any guarantees in that regard.

More importantly though, is that that these two libraries don't even offer 
source compatibility guarantees. Thus, if a distro updates clang, it would not 
be guaranteed that a recompile of kdev-clang is enough to get it working 
again.

Hence, we must be creative in how to solve this issue. The clang-c API is 
stable, thus we use it in kdev-clang and don't have any problems. But for 
libTooling, we will have to find a different way. Thus, I propose you work on 
a separate executable which can be called from KDevelop as needed to do the 
refactoring. But, I rather want you to concentrate on the actual refactoring. 
You can then leave the issues of how to integrate it to us. This GSOC is a 
kind of a research and development project - we want to see what one can do 
with libTooling, and how one could implement useful refactorings with it. Once 
we see that it really is worth it, we can then integrate it into the rest of 
our codebase.
 
> So the question is: how this fact (of having unstable ABI) influences our
> decision? Even if we decide to build separate binary linking with
> libTooling - the same issues will apply to this binary.

If we link against it and then the distro updates clang and our code does not 
compile anymore, we must not disable all of kdev-clang. I'd be OK with it 
disabling only the refactoring features though.

Bye, HTH
-- 
Milian Wolff
mail at milianw.de
http://milianw.de