[cfe-dev] Integrating clang-based refactoring tools into IDEs - best practices?

[Kevin Funk]

On Monday 01 June 2015 07:13:36 Tom Stellard wrote:
> On Mon, Jun 01, 2015 at 03:54:55PM +0200, Kevin Funk wrote:
> > On Saturday 30 May 2015 14:43:44 Milian Wolff wrote:
> > > Hello all,
> > > 
> > > for KDevelop, we have a GSOC student this summer doing a R&D project on
> > > how
> > > we could leverage libTooling and friends to create refactoring tools for
> > > C++ code. I'm pretty sure that this is the correct way in the long run,
> > > but
> > > I have some trouble with the lack of API and ABI stability in the C++
> > > libraries of LLVM, most notably libTooling here.
> > 
> > I just talked to a few people in #llvm and it appears that library ABI
> > from
> > x.y.0 is supposed to be same for x.y.1 and onwards. So there seems to be a
> > ABI stability guarantee for patch releases. (Can someone from LLVM/Clang
> > devs confirm this? Tom Stellard told me it's indeed "official")
> 
> See item #4: http://llvm.org/docs/HowToReleaseLLVM.html#release-patch-rules
> 
> > This combined with the fact that distros usually co-install LLVM/Clang
> > minor releases (3.5, 3.6, ...) should avoid us running in ABI issues, no?
> 3.5 and 3.6 have different ABIs, so you will have to pick one to link
> against unless your project has some kind of wrapper library that allows
> you to support both versions at the same time.

Right, that's what I was referring to. We pick either 3.5 or 3.6 as dependency 
at compile time. Updates to the library then wouldn't cause issues for us, 
since patch releases are supposed to be ABI compatible.

(Personally I didn't know there was such a guarantee in LLVM at all. Good to 
know!)

> -Tom
> 
> > I'd really appreciate if we could just use the libTooling API and share
> > parsed data (somehow...) and avoid the multi-process approach altogether.
> > Maybe that's indeed the better approach for our R&D project -- just use
> > the API directly, don't add a wrapper (yet).
> > 
> > PS: Sorry I didn't step in earlier on the KDevelop mailing list, but I'm
> > buried in "real" work at the moment
> > 
> > > I was thinking about a separate process that works only against a very
> > > specific LLVM version. Thus, if distributors update LLVM, and the stuff
> > > does not compile anymore, we only loose the refactoring but not the
> > > whole language support (based on clang-c).
> > > With this approach though, the cached parse data cannot be shared
> > > between
> > > language support and refactoring...
> > > 
> > > How do other IDEs handle this situation? Is there maybe an external
> > > libTooling-c shim or similar that we could leverage?
> > > 
> > > Bye
> > 
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
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://lists.llvm.org/pipermail/cfe-dev/attachments/20150601/70d53dcf/attachment.sig>