<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Nov 30, 2016 at 10:34 PM Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com">rizsotto.mailinglist@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">thanks Manuel,<br class="gmail_msg"><br class="gmail_msg"></div>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.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- 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?<br class="gmail_msg"></div></div></blockquote><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">- 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?<br class="gmail_msg"></div></div></blockquote><div><br></div><div>You mean the db will contain both? Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">- about linking. (specially static linking.) how would you record that into the existing format?<br class="gmail_msg"></div></div></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">- 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?<br class="gmail_msg"></div></div></blockquote><div><br></div><div>Well, currently it's the right assumption :) Together we're free to change it :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">regards,<br class="gmail_msg"></div><div class="gmail_msg">Laszlo<br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Thu, Dec 1, 2016 at 2:56 AM, Manuel Klimek <span dir="ltr" class="gmail_msg"><<a href="mailto:klimek@google.com" class="gmail_msg" target="_blank">klimek@google.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Nov 30, 2016 at 2:59 AM Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com" class="gmail_msg" target="_blank">rizsotto.mailinglist@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><div class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><div class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><div class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><div class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><div class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg">Hi all,<br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"></div>I wrote a tool (Bear) which generates compilation database. A user feeds the output into a tool which is using Clang tooling libraries. <<a href="https://github.com/woboq/woboq_codebrowser/" class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg" target="_blank">https://github.com/woboq/woboq_codebrowser/</a>> He runs these tools again a project, which contains .s and .asm files. (These files are compiled as `clang -x assembler-with-cpp`)<br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"></div>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?<br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"><br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"></div>Any help or pointer some documentation is appreciated.<br class="m_28800766531520647m_6760034789942032407gmail_msg gmail_msg"></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">The compilation database doesn't really say this, and I kept that unspecified precisely so we could extend it later ;)</div><div class="gmail_msg">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.</div><div class="gmail_msg">Linking might make sense to put in there, if somebody has a use case.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,</div><div class="gmail_msg">/Manuel</div></div></div>
</blockquote></div><br class="gmail_msg"></div>
</blockquote></div></div>