<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Thu, Jun 21, 2012 at 11:42 AM, David Röthlisberger <span dir="ltr"><<a href="mailto:david@rothlis.net" target="_blank">david@rothlis.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 Jun 2012, at 09:32, Manuel Klimek wrote:<br>
> I especially wouldn't want to change the key in the current [compilation<br>
> database] file format due to adding link commands. I'm currently slightly<br>
<div class="im">> leaning towards an extra file, because that leads to tools that only care about<br>
> one part being simpler (and once you add one use case, you start adding other<br>
> use cases ;), but it's not a clear-cut decision.<br>
<br>
</div>Correct me if I'm wrong, but the current file doesn't have an explicit<br>
key. It looks like:<br>
<br>
    [<br>
      { "directory": ...,<br>
        "command": ...,<br>
        "file": ... },<br>
      ...<br>
    ]<br>
<br>
Not like:<br>
<br>
    { "<file>": [{<br>
        "directory": ...,<br>
        "command": ... },<br>
        ...<br>
      ],<br>
      ...<br>
    }<br>
<br>
So users of this compilation database (currently) would have to build<br>
their own index anyway, if they decide they need it for performance<br>
reasons.<br>
<br>
Given the above, I don't think it would hurt to add an extra "output"<br>
element. And while we're at it --before there are too many users--<br>
rename "file" to "input" or something like that. Generate both "file"<br>
and "input" entries for a while, to ease the transition, but mark<br>
"file" as deprecated.<br></blockquote><div><br></div><div>Well, the idea is that "file" specified a main source file for a TU.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Tools for working on C/C++ source files would, I imagine, independently<br>
obtain a list of source files (e.g. "find . -name '*.cpp'") and *then*<br>
look up each file in the compilation database. So it doesn't matter if<br>
the compilation database contains entries for non-source files (like a<br>
link command with input file "something.o"). Please correct me if your<br>
use case differs.<br></blockquote><div><br></div><div>Ah, yes, theoretically it doesn't matter, as long as the tools all understand it and can throw away things they don't need.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Similarly, my vote would be for something like<br>
CMAKE_EXPORT_BUILD_COMMANDS instead of separate<br>
*_COMPILE_COMMANDS and *_LINK_COMMANDS.<br>
<br>
<br>
On 20 Jun 2012, at 20:59, Bertjan Broeksema wrote:<br>
> I'm willing to work on a patch, given that [...] I get some pointers on<br>
<div class="im">> where to start to make it happen.<br>
<br>
</div>The documentation for this compilation database is at<br>
<a href="http://clang.llvm.org/docs/JSONCompilationDatabase.html" target="_blank">http://clang.llvm.org/docs/JSONCompilationDatabase.html</a><br>
<br>
The feature was added to cmake in these 2 commits:<br>
<a href="http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe07b055" target="_blank">http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe07b055</a><br>
<a href="http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5674844d" target="_blank">http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5674844d</a><br>
<br>
Finally, I must point out that I am a very recent member of the clang<br>
community so take my input with a grain of salt.<br></blockquote><div><br></div><div>You raise good points - as I said, which way to chose is not clear cut, and I'd be willing to say whoever implements it wins ;)</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--Dave.<br>
<br>
</blockquote></div><br></font></div>