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

[Laszlo Nagy via cfe-dev]

Another idea about the linkage graph... which might contradict to what I've
just said earlier. :)

Why not use ninja build file for compilation database? That's already
stores the linkage graph. All is needed a reader which takes a ninja build
file and implement the CompilationDatabase interface to work with
libtooling based tools. And for your project another reader that can
extract not only the compilations but the linkages too.

How does that sound for you?

On Tue, Mar 14, 2017 at 11:41 PM, Laszlo Nagy <
rizsotto.mailinglist at gmail.com> wrote:

> 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/20170315/5936e6fe/attachment.html>