[cfe-dev] Getting involved with Clang refactoring
klimek at google.com
Mon May 28 03:42:20 PDT 2012
On Mon, May 28, 2012 at 12:25 PM, Arnaud ALLARD DE GRANDMAISON <
arnaud.allarddegrandmaison at parrot.com> wrote:
> Hi Manuel,
> For your information, I started the work on point #2 : integrating
> compilation database in libclang + the corresponding python binding.
Awesome - feel free to cc me directly to any patches you send out for
review regarding this.
> 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
> 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
> - 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev