<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 3:58 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.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 class=""><div class="h5">On Fri, Jul 19, 2013 at 3:50 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>

><br>
><br>
><br>
> On Fri, Jul 19, 2013 at 12:33 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> On Thu, Jul 18, 2013 at 2:20 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
>>>><br>
>>>> So I'm not completely opposed to the idea. I'd be curious what Chandler<br>
>>>> thinks, he usually happens to have strong opinions about things like this :)<br>
>>><br>
>>><br>
>>> Yeah, I'd love to hear any ideas he has about this.<br>
>><br>
>><br>
>> I'm summoned. =D<br>
>><br>
>> So, I'm moderately opposed to the idea. The reason is that we've tried<br>
>> this (as Manuel mentions) and it creates a really huge new problem: where do<br>
>> you look for the object file. Worse, the *right* object file.<br>
>><br>
>> The primary benefit of writing out to a single compilation database is<br>
>> *precisely* that: it is a *single* compilation database. You can place it in<br>
>> a common, predictable location and have clang-based tools look there. We had<br>
>> huge, never-ending problems with this in practice. We would spend more time<br>
>> looking for the .o file than we would running the clang tool, or we would<br>
>> find the wrong .o file and end up not reproducing the compile developers<br>
>> actually cared about.<br>
><br>
><br>
> Perhaps the commandline flag that enables emitting this information could<br>
> also accept a unique ID to embed along with the information, which would<br>
> allow you to easily decide which files correspond to which build. Would that<br>
> address these issues you cite? If not, could you elaborate?<br>
><br>
>><br>
>><br>
>> Even if you build aggregate databases as you say for "final build<br>
>> products", I agree with Manuel: this just moves the problem. Now you need to<br>
>> know which build product to look into.<br>
><br>
><br>
> I think that "Moving the problem" is actually an important part of this<br>
> proposal. The primary issue in my eyes is getting information from A to B,<br>
> where<br>
><br>
> A = a place that knows what information should be in the compilation<br>
> database<br>
> B = somewhere that a tool can access the compilation database.<br>
><br>
> I can think of two places that qualify for A: 1) The build system and 2) the<br>
> the compiler itself. Changing the build system (either the build program<br>
> itself, or even the "project files") is a non-starter in my environment. So<br>
> that leaves us with using A=the compiler itself (I'm open to other values of<br>
> A, but at the moment these two are the only ones I can think of). Now, the<br>
> question is how do you transport the information to somewhere the tool can<br>
> access it.<br>
><br>
> Basically by definition, a build system allows access to build products, and<br>
> so without any additional assumption, build products are a viable option for<br>
> transporting the information in all build systems. The constraint of not<br>
> modifying existing build configurations leads to the conclusion that these<br>
> build products that we use for transport must be *existing* build products.<br>
><br>
> Simply embedding this information in build products doesn't get us all the<br>
> way from A to B. However, "Moving the problem" to be "given a set of build<br>
> products known to contain all the compilation database information for a<br>
> project, extract a compilation database" is I think a useful simplification<br>
> of the problem "given an arbitrary C/C++ project, extract a compilation<br>
> database". Would you agree?<br>
<br>
</div></div>But that's not where you've moved the problem, because you still have<br>
the problem of "find the set of build products". If a build system<br>
produces 3 binaries - there's no consistent/trivial/generic way to<br>
discover those 3 binaries that I know of.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Typically it is possible to establish some set of files/directories that are a superset of all the build products. Then the following "consistent/trivial/generic" algorithm is sufficient:</div>
<div><br></div><div>for all files in the set of files/directories that is a superset of all build products:</div><div>    check if it contains a compilation database entry</div><div><br></div><div>This relies on an easily-identifiable mark that will only be present in the relevant build products, which I think is feasible to come up with; my idea <span style="font-size:13px;color:rgb(0,0,0);font-family:arial,sans-serif">"@</span><span style="font-size:13px;color:rgb(0,0,0);font-family:arial,sans-serif">ClangCompilationDatabaseEntryM</span><span style="font-size:13px;color:rgb(0,0,0);font-family:arial,sans-serif">D5JSON<hex md5sum of $JSON>$JSON" fits this role adequately I think.</span></div>
<div><br></div><div>-- Sean Silva</div></div><br></div></div>