<div dir="ltr">Hi Whisperity,<div><br><div class="gmail_extra">On Tue, Mar 14, 2017 at 10:58 PM, Whisperity via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But simply saying two one-liner commands which include linkage:<br>
<br>
 // I purposefully omitted the "-o" argument.<br>
 $ clang++ main.cpp 1.cpp<br>
 $ clang++ main.cpp 2.cpp<br>
<br>
Should also show that these files were compiled together. (Right now,<br>
as I see, there is some deduplication happening. And without this<br>
deduplication, clang-check and clang-tidy seems to fail.)<br>
<br>
  [<br>
   {"directory": ".", "file": "main.cpp", "command": "clang++ main.cpp 1.cpp"},<br>
   {"directory": ".", "file": "main.cpp", "command": "clang++ main.cpp 2.cpp"},<br>
   {"directory": ".", "file": "1.cpp", "command": "clang++ main.cpp 1.cpp"},<br>
   {"directory": ".", "file": "2.cpp", "command": "clang++ main.cpp 2.cpp"},<br>
  ]<br></blockquote><div><br></div><div>All I can say from `intercept-build` you not gonna have that output. But rather this:<br><br>  [<br>
   {"directory": ".", "file": "main.cpp", "command": "clang++ -c main.cpp"},<br>   {"directory": ".", "file": "1.cpp", "command": "clang++ -c 1.cpp"},<br>
   {"directory": ".", "file": "2.cpp", "command": "clang++ -c 2.cpp"},<br>
  ]<br><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is why I originally wanted and I still want this to NOT be the<br>
default behaviour, but something that is triggered by a switch. If<br>
your tool can support the understanding of linker commands in the<br>
build.json, you flick this switch, and then you (can) expect an output<br>
that contains link commands. Other tools simply not flick the switch,<br>
and retain the "purely compilation commands only" view.<br>
<br>
So what I want to see is the linkage graph represented in the file. By<br>
parsing the file and examining the data in it, I want to be able to<br>
model which translation units and objects were linked together when<br>
the project was built.<br></blockquote><div><br></div><div>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. ;)<br><br></div><div>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.<br><br></div><div>Laszlo<br></div></div></div></div></div>