[cfe-dev] Extending CMAKE_EXPORT_COMPILE_COMMANDS

[David Röthlisberger]

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.

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.

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


On 20 Jun 2012, at 20:59, Bertjan Broeksema wrote:
> I'm willing to work on a patch, given that [...] I get some pointers on
> where to start to make it happen.

The documentation for this compilation database is at
http://clang.llvm.org/docs/JSONCompilationDatabase.html

The feature was added to cmake in these 2 commits:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe07b055
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5674844d

Finally, I must point out that I am a very recent member of the clang
community so take my input with a grain of salt.

--Dave.