GSOC 2015

Maciej Poleski d82ks8djf82msd83hf8sc02lqb5gh5 at gmail.com
Sat May 30 11:41:15 UTC 2015


Dnia sobota, 30 maja 2015 13:21:32 piszesz:
>  
> > 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
> 

I guess in any case it is not allowed to fail at compile time. We can use conditional compilation (#ifdef) to enable libTooling pieces only when we are sure that appropriate Clang version is available. This doesn't mean that it must be separate target. Compilation of the rest of code base (current kdev-clang) would be unconditional in any case.
But I understand that there may be issue when Clang get update and already compiled code (kdev-clang linked with libTooling) stop working. And that's what we want to avoid. If this is the issue You are concerned about, then indeed I will ship refactorings in separate binary (which we couldn't assume to be in working state at runtime). Is that what You mean?

Best Regards
Maciej Poleski



More information about the KDevelop-devel mailing list