<div dir="ltr"><div><div>Hi Whisperity,<br><br></div>I thought I understood your question on github, but this email is confusing me... Can I ask simple questions to clarify a few things?<br></div><div><br></div><div>Your example is not a valid compilation. Did you try them?<br><br></div><div>  $ clang -c a.c b.c -o ab.o<br>  clang-3.8: error: cannot specify -o when generating multiple output files<br><br>  $ clang a.c b.c -o ab.o<br><br></div><div>The second one compiles iff `a.c` or `b.c` contains `main` implementation. Then `ab.o` becomes not an object file, but an executable. So, that's already a linking!<br><br></div><div>To have duplicated entries in compilation database are not problem. So, if you have the same module multiple times, that's just fine.<br><br></div><div>  $ clang -c a.c -o a.o<br></div><div>  $ clang -c a.c -Dkey=value -o a.o<br><br></div><div>will result two entries where the "file" attribute is the same.<br><br></div><div>  $ clang a.c b.c -o ab<br><br></div><div>As previously explained this is two compilation and one linking. Current tools will generate a compilation database with two entries only.<br><br>  [<br></div><div>   {"directory": ".", "file": "a.c", "command": "cc -c a.c"},<br></div><div><div>   {"directory": ".", "file": "b.c", "command": "cc -c b.c"},<br></div>  ]<br></div><div><br></div><div>My understanding was earlier that you want this to be a three element list. Is that correct? Or you want a single element list?<br><br></div><div>Or even simpler, shall we make an entry for this too?<br><br></div><div>  $ clang a.o b.o -o ab<br><br></div><div>But then, shall we record linker commands like this?<br><br></div><div>  $ ld a.o b.o -o ab<br><br></div><div>Or even this?<br><br></div><div>  $ ar crf lib.a a.o b.o<br><br></div><div>How would you represent these commands in the JSON compilation database?<br><br></div><div>Because my main point was, you need to define this first (via this list, with consent and implementation support) to have the tools (cmake, intercept-build, etc...) to generate the desired output.<br><br></div><div>Regards,<br></div><div>Laszlo<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 8:14 AM, 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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Members,<br>
Dear Manuel Klimek and László Nagy (rizsotto),<br>
<br>
I'm resurrecting an older discussion<br>
(<a href="http://clang-developers.42468.n3.nabble.com/compilation-db-question-td4054364.html" rel="noreferrer" target="_blank">http://clang-developers.<wbr>42468.n3.nabble.com/<wbr>compilation-db-question-<wbr>td4054364.html</a>)<br>
and replying upon my request to include link commands in the<br>
intercept-build's build.json<br>
(<a href="https://github.com/rizsotto/scan-build/issues/80" rel="noreferrer" target="_blank">https://github.com/rizsotto/<wbr>scan-build/issues/80</a>). Here at Ericsson<br>
we develop the tools CodeChecker and CodeCompass. We use the<br>
compilation commands JSON to get the information we need, but neither<br>
CMake's generated database (related discussion:<br>
<a href="http://clang-developers.42468.n3.nabble.com/Extending-CMAKE-EXPORT-COMPILE-COMMANDS-td4024793.html" rel="noreferrer" target="_blank">http://clang-developers.42468.<wbr>n3.nabble.com/Extending-CMAKE-<wbr>EXPORT-COMPILE-COMMANDS-<wbr>td4024793.html</a>)<br>
nor those produced by intercept-build contain linkage commands, which,<br>
in certain cases, our tools need.<br>
For this reason, we have been supplying our own interceptor, LD-LOGGER<br>
(<a href="https://github.com/Ericsson/codechecker/tree/master/vendor/build-logger" rel="noreferrer" target="_blank">https://github.com/Ericsson/<wbr>codechecker/tree/master/<wbr>vendor/build-logger</a>),<br>
but it's messy and unmaintained as of now.<br>
<br>
This is why the request to rizsotto's project has been posted, and he<br>
pointed me in the direction of Clang, but I'd like to get some<br>
pointers before I delve into changing the code.<br>
I've tried some dummy build.jsons and scenarios with the current<br>
(today's morning UTC) LibTooling projects such as clang-check and<br>
clang-tidy.<br>
<br>
Let's consider an example simple project, which is compiled (clang++<br>
-c a.cpp) and then linked (clang++ a.o -o main.out). This will write<br>
TWO entries into the build.json, one with the compile and one with the<br>
linker command, and libtooling programs work with it perfectly, the<br>
link command (valid as per the Compilation Command Database<br>
specification) is not causing any mayhem.<br>
<br>
Now consider the following build commands in the project.<br>
<br>
    clang++ a.cpp b1.cpp -o ab1.o<br>
    clang++ a.cpp b2.cpp -o ab2.o<br>
    clang++ ab1.o c.cpp -o one.out<br>
    clang++ ab2.o d.cpp -o two.out<br>
<br>
If this is logged, either by our tool (with the linkage commands) or<br>
via intercept-build, or -even- if I create a valid build.json for this<br>
project in an editor, the tools clang-tidy and clang-check fail with<br>
the error<br>
     error: unable to handle compilation, expected exactly one compiler job<br>
<br>
Which is understandable, because as of now, a.cpp exists twice in the<br>
compile commands. Actually there are four lines, two with a.cpp as<br>
file, and one-one with b1 and b2, but only two commands are<br>
duplicated. Which is the expected result, seeing how the project is<br>
built in our example. (This, to my understanding, fits the<br>
specification of a CCDb.)<br>
<br>
My questions are:<br>
<br>
1. Is the "only one compiler job" an expectation only standing in<br>
tools like clang-tidy and clang-check who want to "query" the proper<br>
compilation commandline from the build.json and fail into ambiguity if<br>
there are more, or is this a more general expectation?<br>
<br>
2. Rizsotto said, and I quote<br>
<br>
"But very little (or none) support for it in the current Clang tooling<br>
library. (I would call the compilation database parser in Clang very<br>
picky/strict.)<br>
Currently I'm busy to merge this code into Clang repository. Would not<br>
implement this feature now. [...] I can put more effort into it, when<br>
there is a more generic driver from Clang side too. As far as I can<br>
see Manuel (one of the guy behind Clang tooling) is supporting it, but<br>
lack resource to implement it. (Be the change you want! ;))"<br>
<br>
Assuming that I implement logging the build commands into<br>
intercept-build (or Bear), which are the crucial Clang parts which I<br>
should expect to be broken by the fact that linker commands are in the<br>
database? Should there be a filter somewhere, in some project of<br>
Clang, which filters the link commands on some criteria? (In our<br>
tools, we implemented rules based on which we decided whether or not<br>
an entry in ld-logger's output is a compile or a link command.)<br>
<br>
As seen above, to my current understanding, having link commands does<br>
not make LibTooling's head spin around --- but having the same file<br>
referenced multiple time does, at least for some tools.<br>
<br>
3. (This is more directed at Manuel)<br>
Did the thought train move forward since November? What is the current<br>
consensus on this approach? We would like to increase our tools'<br>
support for what is generally used and more maintained in the<br>
community.<br>
<br>
<br>
Best regards,<br>
Whisperity.<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>