GSOC 2015

[Kevin Funk]

On Saturday 30 May 2015 14:37:46 Milian Wolff wrote:
> 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.

See discussion on cfe-dev:

I think we shouldn't start writing wrappers right now. LLVM/Clang apparently 
has some sort of ABI guarantee, at least for patch releases. Which is probably 
enough for us. So we could indeed link against the distro-provided libraries.

> 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.

Yes, please let's go this way first. We can think of hacks later on :)
 
> 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

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- 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/20150601/5868cd7c/attachment.sig>