[cfe-dev] Getting involved with Clang refactoring

[Manuel Klimek]

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

Yep. Unfortunately I think that ship has sailed for make a long time
ago... This might be an option for ninja integration though...

Cheers,
/Manuel