On Thu, May 24, 2012 at 11:39 PM, James K. Lowden <span dir="ltr"><<a href="mailto:jklowden@schemamania.org" target="_blank">jklowden@schemamania.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, 22 May 2012 15:49:42 +0200<br>
Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
<br>
> > Gentlemen, could you tell me please what you mean by a "compilation<br>
> > database"?  It sounds like a list of files to compile, something I'd<br>
> > normally look to make(1) to provide.  Apparently that's not what you<br>
> > mean, or there's some reason make won't do the job.<br>
> ><br>
> > If I understood the problem better perhaps there's something I<br>
> > could do about it.<br>
><br>
> The problem with make is that it executes the compiler based on<br>
> changes in the dependency graph.<br>
><br>
> Imagine you want to run a tool on all files that use a specific<br>
> symbol. To do this you need to:<br>
> 1. figure out the compile command line for the file into which you're<br>
> pointing to figure out the symbol under the cursor<br>
> 2. run the tool over all files that reference that symbol<br>
<br>
</div>3.  In an order determined by the dependency graph.  :-)<br></blockquote><div><br></div><div>No, in one process at the same time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Thank you for the explanation.  At least now I partly understand what<br>
you're talking about.<br>
<br>
But I'm still puzzled.  Why would one need to recompile all files that<br>
use a specific symbol? Changes to a symbol normally occur in a header<br>
file, affecting the dependency graph in just the way that makes make<br>
useful.  To solve the problem you describe -- to have Clang recompile<br>
"all files that use a specific symbol"  -- one could touch(1) all such<br>
files and then run make.<br></blockquote><div><br></div><div>Not all build systems work on system time. Some work on content digests. Even if this worked, the amount of stats that build systems do in ReallyLargeCodeBases to figure out what to build can be a huge cost, and can actually dwarf the time it takes to reparse 3 or 4 files you care about.</div>
<div><br></div><div>And there's one more reason: for example, I want to rename some symbol. I need all files to parse before the refactoring and after the refactoring, as broken files lead to problems in the AST.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The "figure out the command line" part is also intrinsic to make, as<br>
you know, based on the filename suffix.  That's 30 years of prior art<br>
that the compilation database seems to be reinventing.<br></blockquote><div><br></div><div>I think this argument is way to generic. It seems to me like most innovations look like this at first. I might be wrong, but at least let me try ;)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand the project has an existing build infrastructure, and that<br>
the compilation database is already embedded in it.  It's not yet clear<br>
to me why it was invented, and whether it's a solution or a problem.<br></blockquote><div><br></div><div>It was definitely invented by multiple people independently in different shades:</div><div>For example, look at how clang-complete works - it requires you to have a simplified compilation database (one compile command that works for all files you work with) in your project. This does not work for a large set of projects, though.</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div><div><br></div></div>