Looping in chandlerc for an opinion :)<br><br><div class="gmail_quote">On Mon, Jun 25, 2012 at 8:25 PM, Bertjan Broeksema <span dir="ltr"><<a href="mailto:broeksema@kde.org" target="_blank">broeksema@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Manuel Klimek wrote:<br>
<br>
> On Thu, Jun 21, 2012 at 11:42 AM, David Röthlisberger<br>
> <<a href="mailto:david@rothlis.net">david@rothlis.net</a>>wrote:<br>
><br>
>> On 21 Jun 2012, at 09:32, Manuel Klimek wrote:<br>
>> > I especially wouldn't want to change the key in the current<br>
>> > [compilation database] file format due to adding link commands. I'm<br>
>> > currently slightly leaning towards an extra file, because that leads to<br>
>> > tools that only<br>
>> care about<br>
>> > one part being simpler (and once you add one use case, you start adding<br>
>> other<br>
>> > use cases ;), but it's not a clear-cut decision.<br>
>><br>
>> 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>
>><br>
><br>
> Well, the idea is that "file" specified a main source file for a TU.<br>
><br>
><br>
>> Tools for working on C/C++ source files would, I imagine, independently<br>
</div></div>>> obtain a list of source files (e.g. "find . -name '*.cpp'") and then<br>
<div class="im HOEnZb">>> 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>
>><br>
><br>
> Ah, yes, theoretically it doesn't matter, as long as the tools all<br>
> understand it and can throw away things they don't need.<br>
<br>
</div><div class="im HOEnZb">And for the linker part: I'd like to pass the command line as well to find<br>
the libraries against which an executable/librarie is linked as well other<br>
settings passed to the linker such as search directories and rpath.<br>
<br>
</div><div class="im HOEnZb">>> Similarly, my vote would be for something like<br>
>> CMAKE_EXPORT_BUILD_COMMANDS instead of separate<br>
>> *_COMPILE_COMMANDS and *_LINK_COMMANDS.<br>
<br>
</div><div class="HOEnZb"><div class="h5">I'm in favor of this as well, though for me its just a spare time project<br>
so<br>
if others have reasons related to scalability that are important to them, I<br>
can live with a separete file as well. I don't see how this would be<br>
formatted though, to be similar to the current file format. I suppose<br>
something like:<br>
<br>
// For compilation<br>
{ "directory": ...,<br>
"command": ...,<br>
"input": <sourcefile>,<br>
"ouput": <sourcefile>.o<br>
}<br>
<br>
// For linking<br>
{ "directory": ...,<br>
"command": ...,<br>
"input": [<list of files here>] },<br>
"ouput": <lib_or_exec_name><br>
}<br>
<br>
Eventually one could add an extra level of properties to distinguish<br>
between<br>
the two types:<br>
<br>
{<br>
compilations: [<br>
{ <compilation_objects }<br>
],<br>
linkcommands: [<br>
{ <compilation_objects }<br>
]<br>
}<br>
<br>
To me that is a bit cleaner, but likely requires more work to existing<br>
tools<br>
that already use the format. In stead of that, an extra option can be set<br>
on<br>
each object:<br>
<br>
{ "directory": ...,<br>
"command": ...,<br>
"input": [<list of files here>] },<br>
"ouput": <lib_or_exec_name><br>
"type": <link|compilation><br>
}<br>
<br>
<br>
</div></div><div class="im HOEnZb">> You raise good points - as I said, which way to chose is not clear cut,<br>
> and I'd be willing to say whoever implements it wins ;)<br>
<br>
</div><div class="im HOEnZb">Hehe, so I implement it however I want for my spare time project and burden<br>
people who use it in their daily work with some over engineered format =:).<br>
<br>
No, really, I just brought it up because this CMake extension looked really<br>
useful to me and if it exports the additional information, it makes life<br>
for<br>
me a bit easier. I'm willing to do the implementation, I just don't want to<br>
implement something that is rejected because others would have seen it<br>
differently after they see the implementation.<br>
<br>
So I prefer to settle for a solution first, then I'll sit down and add the<br>
feature.<br>
<br>
Cheers,<br>
<br>
Bertjan<br>
<br>
p.s. My reaction time is illustrating for what spare time means in my<br>
context =:)<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>