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

[Whisperity via cfe-dev]

The problem with this is that using the "ninja build file" implies
that a "ninja build file" exists, or that we are able to generate it.

Which might not be the case. A (very) quick google search didn't turn
up any meaningful way to transform an existing Makefile into a ninja
build file, or even make an autotools project compile for ninja.

Of course, CMake can generate a ninja build file, but that, while
resolves the assumption/expctation that "ninja build file exists", it
creates a new expectation, that there is a CMake project from which
the ninja build file could be generated.

2017-03-14 14:04 GMT+01:00 Laszlo Nagy <rizsotto.mailinglist at gmail.com>:
> 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
>
>