<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 12:33 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br>
<div class="gmail_quote">On Thu, Jul 18, 2013 at 2:20 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div>So I'm not completely opposed to the idea. I'd be curious what Chandler thinks, he usually happens to have strong opinions about things like this :)</div></div>

</div></div></blockquote><div><br>
</div></div><div>Yeah, I'd love to hear any ideas he has about this.</div></blockquote></div><br></div>I'm summoned. =D</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, I'm moderately opposed to the idea. The reason is that we've tried this (as Manuel mentions) and it creates a really huge new problem: where do you look for the object file. Worse, the *right* object file.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">The primary benefit of writing out to a single compilation database is *precisely* that: it is a *single* compilation database. You can place it in a common, predictable location and have clang-based tools look there. We had huge, never-ending problems with this in practice. We would spend more time looking for the .o file than we would running the clang tool, or we would find the wrong .o file and end up not reproducing the compile developers actually cared about.</div>
</div></blockquote><div><br></div><div>Perhaps the commandline flag that enables emitting this information could also accept a unique ID to embed along with the information, which would allow you to easily decide which files correspond to which build. Would that address these issues you cite? If not, could you elaborate?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><br></div><div class="gmail_extra">Even if you build aggregate databases as you say for "final build products", I agree with Manuel: this just moves the problem. Now you need to know which build product to look into.</div>
</div></blockquote><div><br></div><div>I think that "Moving the problem" is actually an important part of this proposal. The primary issue in my eyes is getting information from A to B, where</div><div><br></div>
<div>A = a place that knows what information should be in the compilation database</div><div>B = somewhere that a tool can access the compilation database.</div><div><br></div><div>I can think of two places that qualify for A: 1) The build system and 2) the the compiler itself. Changing the build system (either the build program itself, or even the "project files") is a non-starter in my environment. So that leaves us with using A=the compiler itself (I'm open to other values of A, but at the moment these two are the only ones I can think of). Now, the question is how do you transport the information to somewhere the tool can access it.</div>
<div><br></div><div>Basically by definition, a build system allows access to build products, and so without any additional assumption, build products are a viable option for transporting the information in all build systems. The constraint of not modifying existing build configurations leads to the conclusion that these build products that we use for transport must be *existing* build products.</div>
<div><br></div><div>Simply embedding this information in build products doesn't get us all the way from A to B. However, "Moving the problem" to be "given a set of build products known to contain all the compilation database information for a project, extract a compilation database" is I think a useful simplification of the problem "given an arbitrary C/C++ project, extract a compilation database". Would you agree?</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">

<div class="gmail_extra"><br></div><div class="gmail_extra">I genuinely think that having a common database is far and away the best strategy for integrating tools into a development process. We should focus on updating build systems to directly write out these databases. That tends to be the most effective way to get the compilation database.</div>

</div>
</blockquote></div><br></div></div>