[cfe-dev] Extending CMAKE_EXPORT_COMPILE_COMMANDS

[Bertjan Broeksema]

Manuel Klimek wrote:

> On Thu, Jun 21, 2012 at 11:42 AM, David Röthlisberger
> <david at rothlis.net>wrote:
> 
>> On 21 Jun 2012, at 09:32, Manuel Klimek wrote:
>> > I especially wouldn't want to change the key in the current
>> > [compilation database] file format due to adding link commands. I'm
>> > currently slightly leaning towards an extra file, because that leads to
>> > tools that only
>> care about
>> > one part being simpler (and once you add one use case, you start adding
>> other
>> > use cases ;), but it's not a clear-cut decision.
>>
>> Correct me if I'm wrong, but the current file doesn't have an explicit
>> key. It looks like:
>>
>>    [
>>      { "directory": ...,
>>        "command": ...,
>>        "file": ... },
>>      ...
>>    ]
>>
>> Not like:
>>
>>    { "<file>": [{
>>        "directory": ...,
>>        "command": ... },
>>        ...
>>      ],
>>      ...
>>    }
>>
>> So users of this compilation database (currently) would have to build
>> their own index anyway, if they decide they need it for performance
>> reasons.
>>
>> Given the above, I don't think it would hurt to add an extra "output"
>> element. And while we're at it --before there are too many users--
>> rename "file" to "input" or something like that. Generate both "file"
>> and "input" entries for a while, to ease the transition, but mark
>> "file" as deprecated.
>>
> 
> Well, the idea is that "file" specified a main source file for a TU.
> 
> 
>> Tools for working on C/C++ source files would, I imagine, independently
>> obtain a list of source files (e.g. "find . -name '*.cpp'") and then
>> look up each file in the compilation database. So it doesn't matter if
>> the compilation database contains entries for non-source files (like a
>> link command with input file "something.o"). Please correct me if your
>> use case differs.
>>
> 
> Ah, yes, theoretically it doesn't matter, as long as the tools all
> understand it and can throw away things they don't need.

And for the linker part: I'd like to pass the command line as well to find 
the libraries against which an executable/librarie is linked as well other 
settings passed to the linker such as search directories and rpath.

>> Similarly, my vote would be for something like
>> CMAKE_EXPORT_BUILD_COMMANDS instead of separate
>> *_COMPILE_COMMANDS and *_LINK_COMMANDS.

I'm in favor of this as well, though for me its just a spare time project 
so 
if others have reasons related to scalability that are important to them, I 
can live with a separete file as well. I don't see how this would be 
formatted though, to be similar to the current file format. I suppose 
something like:

// For compilation
{ "directory": ...,
   "command": ...,
   "input": <sourcefile>,
   "ouput": <sourcefile>.o
}

// For linking
{ "directory": ...,
   "command": ...,
   "input": [<list of files here>] },
   "ouput": <lib_or_exec_name>
}

Eventually one could add an extra level of properties to distinguish 
between 
the two types:

{
  compilations: [
    { <compilation_objects }
  ],
  linkcommands: [
    { <compilation_objects }
  ]
}

To me that is a bit cleaner, but likely requires more work to existing 
tools 
that already use the format. In stead of that, an extra option can be set 
on 
each object:

{ "directory": ...,
   "command": ...,
   "input": [<list of files here>] },
   "ouput": <lib_or_exec_name>
   "type": <link|compilation>
}
  

> 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 ;)

Hehe, so I implement it however I want for my spare time project and burden 
people who use it in their daily work with some over engineered format =:). 

No, really, I just brought it up because this CMake extension looked really 
useful to me and if it exports the additional information, it makes life 
for 
me a bit easier. I'm willing to do the implementation, I just don't want to 
implement something that is rejected because others would have seen it 
differently after they see the implementation.

So I prefer to settle for a solution first, then I'll sit down and add the 
feature.

Cheers,

Bertjan

p.s. My reaction time is illustrating for what spare time means in my 
context =:)