<div class="gmail_quote">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><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>One more reason: dependency order introduces artificial serialization. When you want to analyze code (e.g. run a tool over all code in a project to collect data), you can do so fully parallel with the compilation database and a simple call to xargs. This might not be a huge issue for small code bases (for llvm I get ~2x speedup vs. the cmake generated Makefiles, which are again ~2x vs. the autoconf Makefiles), but for larger projects serialization becomes a major issue.</div>
<div><br></div><div>Cheers,</div><div>/Manuel</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>
<br>
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>
<br>
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>
<span class="HOEnZb"><font color="#888888"><br>
--jkl<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>