[cfe-dev] Getting involved with Clang refactoring

[Manuel Klimek]

On Tue, May 22, 2012 at 4:17 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> 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' :(

/me pulls out the fry meme. Are you actually serious?

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

+1 on that one; I think if we really want generic support, this is the
way to go. I assume the idea is to have
-fcompilation-database=/path/to/db on every TU and then add the TU's
compilation information to that db (including locking etc)?

Cheers,
/Manuel