[cfe-commits] Design proposal: Add custom compilation database formats as plugins

[Daniel Jasper]

Hi Doug,

any chance I could get this reviewed? I have another feature for the
compilation database (correctly handling relative directories) that I would
like to implement in the new structure.

Cheers,
Daniel


On Mon, Jul 23, 2012 at 1:11 PM, Daniel Jasper <djasper at google.com> wrote:

> Any thoughts on this design?
> Cheers,
> Daniel
>
>
> On Fri, Jul 20, 2012 at 2:11 PM, Daniel Jasper <djasper at google.com> wrote:
>
>> I moved the class-comment back and properly propagated the error instead
>> of printing it to outs(). I don't know about using Diagnostics. Could we
>> get to that in a different patch to clearly separate those changes?
>>
>> Cheers,
>> Daniel
>>
>>
>> On Fri, Jul 20, 2012 at 12:41 PM, Manuel Klimek <klimek at google.com>wrote:
>>
>>> I'd like the class-comment for JSONCompilationDatabase to still
>>> include what's now in the file comment, so it's visible in doxygen.
>>>
>>> Also, I'd prefer to use a result value to capture the error message
>>> instead of llvm::outs'ing in findCompilationDatabaseFromDirectory.
>>> Perhaps we should also switch this to Diagnostics?
>>>
>>> Cheers,
>>> /Manuel
>>>
>>> On Fri, Jul 20, 2012 at 12:30 PM, Daniel Jasper <djasper at google.com>
>>> wrote:
>>> > Attached is a patch to do most of this restructuring, kindly asking for
>>> > review.
>>> >
>>> > In particular, it does:
>>> > - Restructure the compilation database architecture to using LLVM's
>>> registry
>>> > concept. It should now be possible to link in additional compilation
>>> > databases.
>>> > - Separate the JSONCompilationDatabase from CompilationDatabase to
>>> show the
>>> > loose coupling and serve as an example.
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Jul 19, 2012 at 3:17 PM, Stephen Kelly <steveire at gmail.com>
>>> wrote:
>>> >>
>>> >> On 07/19/2012 01:32 PM, Manuel Klimek wrote:
>>> >> > On Thu, Jul 19, 2012 at 1:10 PM, Stephen Kelly <steveire at gmail.com>
>>> >> > wrote:
>>> >> >> Chandler Carruth wrote:
>>> >> >>
>>> >> >>> That said, the latest version of CMake already has support for
>>> JSON +
>>> >> >>> Ninja -- we didn't contribute it, so I don't know what strategy
>>> they
>>> >> >>> followed, but you should look at that and talk to the ninja and
>>> CMake
>>> >> >>> developers before going too far here.
>>> >> >>>
>>> >> >> I wrote it and pretty much followed the same thing Manuel did in
>>> the
>>> >> >> Makefile generator.
>>> >> >>
>>> >> >> The commit which actually adds the feature is trivial:
>>> >> >>
>>> >> >>
>>> >> >>
>>> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db839bec7d076b54c5e9ad0d19386a26557a509e
>>> >> >>
>>> >> >> Manuel mentioned before that he'd like to see ninja being able to
>>> >> >> generate a
>>> >> >> database without cmake too though:
>>> >> >>
>>> >> >>
>>> >> >>
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3678/focus=3697
>>> >> >>
>>> >> >> As Chandler said, it's not in a release yet, but will be in the
>>> next
>>> >> >> release
>>> >> >> in a few weeks. Feel free to test the release candidate (I would
>>> >> >> appreciate
>>> >> >> if you did)
>>> >> > I know multiple people who are refusing to work without this any
>>> more,
>>> >> > I've been using it since it landed in "next". So consider this part
>>> >> > pretty well tested (at least on the llvm codebase).
>>> >> >
>>> >>
>>> >> Good to hear :)
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Steve.
>>> >>
>>> >> _______________________________________________
>>> >> cfe-commits mailing list
>>> >> cfe-commits at cs.uiuc.edu
>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>> >
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120730/521430e6/attachment.html>