[cfe-dev] compilation db question
Manuel Klimek via cfe-dev
cfe-dev at lists.llvm.org
Thu Dec 1 01:01:30 PST 2016
On Wed, Nov 30, 2016 at 10:34 PM Laszlo Nagy <rizsotto.mailinglist at gmail.com>
wrote:
> thanks Manuel,
>
> interesting what you say. can you comment/hint some other issues i was
> learned from users? would like to build a better understanding what is the
> responsibility of compilation database generators and tooling
> infrastructure.
>
> - compilation flags like -MD, -MT x, -MF x, etc... might cause "duplicate"
> items in the compilation database. (the only difference would be the
> presence of these flags) i did modify the command line and filter out these
> flags. but if i'm following your logic, tooling libs shall notice that
> there is no semantic difference between the two compilation and run only
> once. (which is not the case now) would you be happy with that?
>
If there's no semantic difference, I'd argue that there should only be one
entry in the compilation db. On the other hand, I'd not object to patches
making the tooling infra deduplicate :)
> - compilations when a single command compiles (and links) files together
> are splitted into multiple entries. `clang one.c two.c` will make
> '[{"file": "one.c", "command": "clang -c one.c"}, {"file": "two.c",
> "command": "clang -c two.c"}]' is such transformation is acceptable for you
> point of view?
>
You mean the db will contain both? Sure.
> - about linking. (specially static linking.) how would you record that
> into the existing format?
>
Haven't thought about it in detail yet - but with the late addition of
output files, it seems straight forward to record the linker command?
> - the Bear tool is currently filtering out linker flags. because my
> understanding was that the output will be used by tools which does not go
> beyond compilation. is that a wrong assumption too?
>
Well, currently it's the right assumption :) Together we're free to change
it :)
>
> regards,
> Laszlo
>
> On Thu, Dec 1, 2016 at 2:56 AM, Manuel Klimek <klimek at google.com> wrote:
>
> On Wed, Nov 30, 2016 at 2:59 AM Laszlo Nagy <
> rizsotto.mailinglist at gmail.com> wrote:
>
> Hi all,
>
> I wrote a tool (Bear) which generates compilation database. A user feeds
> the output into a tool which is using Clang tooling libraries. <
> https://github.com/woboq/woboq_codebrowser/> He runs these tools again a
> project, which contains .s and .asm files. (These files are compiled as
> `clang -x assembler-with-cpp`)
>
> When the .s and .asm files are not in the compilation database, the
> codebrowser output is not complete. What I'm trying to figure out here, is
> it a legitimate compilation database which has .s or .asm files in it? Is
> it the responsibility of the tooling library to ignore/consider those
> entries even if those are not real compilations? If that's okay, why
> linking/preprocessing is not part of the compilation database too?
>
> Any help or pointer some documentation is appreciated.
>
>
> The compilation database doesn't really say this, and I kept that
> unspecified precisely so we could extend it later ;)
> Preprocessing is not an extra step (at least in C++ afaiu it's very
> tightly ingrained in the language), so I don't think pulling it out makes
> sense.
> Linking might make sense to put in there, if somebody has a use case.
>
> I'd generally say that tool infrastructure should be able to figure out
> what the tool is interested in, so I'd file bugs / send patches where that
> doesn't work out of the box.
>
> Cheers,
> /Manuel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161201/10a7fcc2/attachment.html>
More information about the cfe-dev
mailing list