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

[Whisperity via cfe-dev]

Sure, here's a dummy project.
Let's assume the following Makefile.

all:
        g++ -std=c++11 main.cpp MyType.cpp impl1.cpp
        g++ -std=c++11 main.cpp MyType.cpp impl2.cpp
        g++ -std=c++11 main.cpp MyType_custom.cpp impl1.cpp
        g++ -std=c++11 main.cpp MyType_custom.cpp impl2.cpp
        g++ -std=c++11 other.cpp

ownfiles:
        g++ -std=c++11 main.cpp MyType.cpp impl1.cpp -o impl1.out
        g++ -std=c++11 main.cpp MyType.cpp impl2.cpp -o impl2.out
        g++ -std=c++11 main.cpp MyType_custom.cpp impl1.cpp -o impl1c.out
        g++ -std=c++11 main.cpp MyType_custom.cpp impl2.cpp -o impl2c.out
        g++ -std=c++11 other.cpp -o other.out


I have attached, to this mail, the corresponding outputs. They are
roughly the same, because each command invoked is a one-liner which
compiles -and- builds. (In case of us having a link command, it would
be as I explained earlier, the file: key being the object file.)

But let me copy the most important information to the body of the mail:

    {
        "directory": "/home/whisperity/untitled",
        "command": "g++ [yadda] -std=c++11
/home/whisperity/untitled/main.cpp
/home/whisperity/untitled/MyType.cpp
/home/whisperity/untitled/impl1.cpp",
        "file": "/home/whisperity/untitled/main.cpp"
    },
    {
        "directory": "/home/whisperity/untitled",
        "command": "g++ [yadda] -std=c++11
/home/whisperity/untitled/main.cpp
/home/whisperity/untitled/MyType.cpp
/home/whisperity/untitled/impl2.cpp",
        "file": "/home/whisperity/untitled/main.cpp"
    }

>From the command, we see, that there was an object or binary formed
(albeit we don't know its name) by using "main-MyType-impl1" and
another by using "main-MyType-impl2".

Actually we -could- be up for a new file, but isn't creating an
entirely new file and format and pushing it through much harder to
implement than a few filters in the existing tooling?

2017-03-14 13:41 GMT+01:00 Laszlo Nagy <rizsotto.mailinglist at gmail.com>:
> 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 --------------
A non-text attachment was scrubbed...
Name: all.build.json
Type: application/json
Size: 5146 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170314/7412b841/attachment.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ownfiles.build.json
Type: application/json
Size: 5659 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170314/7412b841/attachment-0001.json>