[cfe-dev] Extending CMAKE_EXPORT_COMPILE_COMMANDS

[Manuel Klimek]

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.


> 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.
>

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

Cheers,
/Manuel


>
> --Dave.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120621/a9290541/attachment.html>