[cfe-dev] (LibTooling) (scan-build-py) Link commands in the CompilationDatabase JSON

[Laszlo Nagy via cfe-dev]

Hi Whisperity,

On Tue, Mar 14, 2017 at 10:58 PM, Whisperity via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> But simply saying two one-liner commands which include linkage:
>
>  // I purposefully omitted the "-o" argument.
>  $ clang++ main.cpp 1.cpp
>  $ clang++ main.cpp 2.cpp
>
> Should also show that these files were compiled together. (Right now,
> as I see, there is some deduplication happening. And without this
> deduplication, clang-check and clang-tidy seems to fail.)
>
>   [
>    {"directory": ".", "file": "main.cpp", "command": "clang++ main.cpp
> 1.cpp"},
>    {"directory": ".", "file": "main.cpp", "command": "clang++ main.cpp
> 2.cpp"},
>    {"directory": ".", "file": "1.cpp", "command": "clang++ main.cpp
> 1.cpp"},
>    {"directory": ".", "file": "2.cpp", "command": "clang++ main.cpp
> 2.cpp"},
>   ]
>

All I can say from `intercept-build` you not gonna have that output. But
rather this:

  [
   {"directory": ".", "file": "main.cpp", "command": "clang++ -c main.cpp"},
   {"directory": ".", "file": "1.cpp", "command": "clang++ -c 1.cpp"},
   {"directory": ".", "file": "2.cpp", "command": "clang++ -c 2.cpp"},
  ]

Which shall be fine for Clang based tools, because these are only
compilations. This transformation of the commands were discussed in the
earlier thread (you linked that in your mail).


> This is why I originally wanted and I still want this to NOT be the
> default behaviour, but something that is triggered by a switch. If
> your tool can support the understanding of linker commands in the
> build.json, you flick this switch, and then you (can) expect an output
> that contains link commands. Other tools simply not flick the switch,
> and retain the "purely compilation commands only" view.
>
> So what I want to see is the linkage graph represented in the file. By
> parsing the file and examining the data in it, I want to be able to
> model which translation units and objects were linked together when
> the project was built.
>

I think that is a good idea to track which module contributed to which
artifact. (You called it linkage graph.) The question to me is this linkage
graph can fit into the JSON compilation database, or is it a new thing? I
proposed to "extend" the JSON compilation database format, that a full
linkage graph can be described by that. It's much harder to convince this
community and have consent and get support from tooling library, than
invent another file format for your tools and use-cases. But maybe, if it's
a good idea, and it meets other people needs so you contribute to a greater
good. ;)

Can you show us what is the 'build.json' file looks like for your project?
To see how far is it from the current compilation database.

Laszlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170314/ff6477aa/attachment.html>