[cfe-dev] Getting involved with Clang refactoring

Douglas Gregor dgregor at apple.com
Tue May 22 07:17:49 PDT 2012


On May 22, 2012, at 6:49 AM, Manuel Klimek <klimek at google.com> wrote:

> On Tue, May 22, 2012 at 3:19 PM, James K. Lowden
> <jklowden at schemamania.org> wrote:
>> On Mon, 21 May 2012 10:56:51 -0700
>> Douglas Gregor <dgregor at apple.com> wrote:
>> 
>>>> And while I'm at it. One thing that might be interesting for a
>>>> contribution is getting the compilation database support up for
>>>> libclang
>> ...
>>> That's a good idea. libclang assumes that you have your own
>>> compilation database (or similar) and that you use it up feed command
>>> lines to libclang, but it would be easier to use libclang if we could
>>> just point it at a build or source tree and then feed source files to
>>> libclang.
>> 
>> Gentlemen, could you tell me please what you mean by a "compilation
>> database"?  It sounds like a list of files to compile, something I'd
>> normally look to make(1) to provide.  Apparently that's not what you
>> mean, or there's some reason make won't do the job.
>> 
>> If I understood the problem better perhaps there's something I could do
>> about it.
> 
> The problem with make is that it executes the compiler based on
> changes in the dependency graph.
> 
> Imagine you want to run a tool on all files that use a specific
> symbol. To do this you need to:
> 1. figure out the compile command line for the file into which you're
> pointing to figure out the symbol under the cursor
> 2. run the tool over all files that reference that symbol
> 
> Both steps are completely independent of any dependency changes, so
> running the tool as part of make / as a clang plugin is not the best
> option here. You want a compilation database out of which you can
> quickly (for interactive use cases) get the compile command line for
> any file in a project.
> 
> LibTooling has this idea already at its core:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/CompilationDatabase.h?view=markup
> 
> You first generate a compilation database, and then feed that into
> your tool run.


Bringing it back to 'make' a little bit... we could, conceivably, have a compilation database implicitly generated from the makefiles. If one asked it how to build 'foo.cpp', it would find the appropriate make rule and form the command-line arguments. We don't have such a 'live' compilation database right now, but it fits into the model and would be really, really cool because it would allow us to 'just work' on a makefile-based project. Unfortunately, it amounts to re-implementing 'make' :(

There are other ways we could build compilation databases. There's CMake support for dumping out a compilation database; we could also add a -fcompilation-database=<blah> flag that creates a compilation database as the result of a build, which would work with any build system. That would also be a nice little project that would help the tooling effort.

	- Doug



More information about the cfe-dev mailing list