[cfe-dev] Getting involved with Clang refactoring

[Douglas Gregor]

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

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


About re-implementing 'make'? No, we don't want that burden.

But viewing an existing build system, as implemented in a library that we can link against, through the lens of a compilation database would be useful.

	- Doug