David Röthlisberger david at rothlis.net
Thu Jun 21 02:42:06 PDT 2012

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

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

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

The feature was added to cmake in these 2 commits:

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.


More information about the cfe-dev mailing list