[cfe-dev] Getting involved with Clang refactoring

Arnaud ALLARD DE GRANDMAISON arnaud.allarddegrandmaison at parrot.com
Mon May 28 03:25:43 PDT 2012


Hi Manuel,

For your information, I started the work on point #2 : integrating compilation database in libclang + the corresponding python binding.

Cheers,
Arnaude de Grandmaison
________________________________________
From: Manuel Klimek [klimek at google.com]
Sent: Thursday, May 24, 2012 5:33 PM
To: Arnaud ALLARD DE GRANDMAISON
Cc: David Röthlisberger; cfe-dev at cs.uiuc.edu Developers
Subject: Re: [cfe-dev] Getting involved with Clang refactoring

On Thu, May 24, 2012 at 4:11 PM, Arnaud de Grandmaison <arnaud.allarddegrandmaison at parrot.com<mailto:arnaud.allarddegrandmaison at parrot.com>> wrote:
On 05/24/2012 02:28 PM, Manuel Klimek wrote:
> In the end it depends on who's willing to write which solution and
> propose a patch to clang ;)
Do not tempt me ;)

The use case I have here is that several people are using clang_complete
+ vim, but have to use gcc because their target requires it. We have
added a cmake target to generate the ".clang_complete" configuration
file, which provides the options necessary for compiling the source
files :  in essence, that's a compilation-db. On its side,
clang_complete also provides a script to extract the compilation options
from the build system.

I am interested in working on this compilationdb, as this will clearly
be a benefit for clang and all derivative projects.

So, there are multiple things to the CompilationDatabase where work is needed:

1. Add ways to create the JSON compilation-db. We already have a way to create it from CMake, there were discussions on getting it out of ninja, and even creating one yourself with a python script is not too hard.

2. Integrating the compilation database into libclang, as tools like clang-complete are libclang based, which currently doesn't expose the CompilationDatabase interfaces; adding a C interface around CompilationDatabase would help there.

3. Making CompilationDatabase work in more use cases:
- add code to deal with gcc specific flags, where people have gcc as their main tool; don't know whether it makes sense to add code to deal with other compilers
- add other formats for the CompilationDatabase, for example for Ninja it might be viable to basically link in a Ninja runtime (if available at clang compile time) to directly read the compile commands from the ninja files

Cheers,
/Manuel





More information about the cfe-dev mailing list