GSOC 2015

[Milian Wolff]

On Saturday 30 May 2015 13:41:15 Maciej Poleski wrote:
> 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?

Both are issues. So I still fear that a separate binary will be the final 
solution.

Thinking a bit more about it though: If you feel uncomfortable with this, feel 
free to ignore this and just try to link against libTooling from inside kdev-
clang directly. Then you'll have to work in a sperate branch and we can think 
about how we integrate this mess in the long run.

As I said, I want you to concentrate on actually writing refactoring helpers.

I'll send a mail to the clang ML asking for input on how others are handling 
this.

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