<div class="gmail_quote">On Fri, May 25, 2012 at 5:19 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 Fri, 25 May 2012 07:42:46 +0200<br>
Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
<br>
> 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<br>
> > recompile "all files that use a specific symbol"  -- one could touch<br>
> > (1) all such files and then run make.<br>
><br>
> Not all build systems work on system time. Some work on content<br>
> digests.<br>
<br>
</div>I don't know what you mean by "content digests", unless you're talking<br>
about some kind of fingerprint (e.g. MD5) to determine if the content<br>
has changed.  That's clearly insufficient if a header file changes.<br></blockquote><div><br></div><div>Yes, I mean a fingerprint like md5.</div><div>I don't understand how this is different to timestamps when it comes to header files - the headers need to be in the dependency graph anyways.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Even if this worked, the amount of stats that build systems<br>
> do in ReallyLargeCodeBases to figure out what to build can be a huge<br>
> cost, and can actually dwarf the time it takes to reparse 3 or 4<br>
> files you care about.<br>
<br>
</div>I doubt that.  Could you point me to research supporting that claim?<br></blockquote><div><br></div><div>No. I can point you to my anecdotal experience with networked file systems and code bases that are so large that you don't want to check out everything at once.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Experience in pkgsrc shows that recursive make is very slow over<br>
large trees, and that the problem is the process overhead, not solving<br>
the graph.<br>
<br>
If you haven't read it, I recommend Peter MIller's "Recursive Make<br>
Considered Harmful" (<a href="http://aegis.sourceforge.net/auug97.pdf" target="_blank">http://aegis.sourceforge.net/auug97.pdf</a>). It's a<br>
trove of information about misinformation around make.<br>
<div class="im"><br>
> One more reason: dependency order introduces artificial<br>
> serialization.<br>
<br>
</div>Are you saying the dependencies of static analysis are lesser than for<br>
compilation?  I would think that's ultimately untrue, given that<br>
eventually static analysis would have to be applied to the whole<br>
program, even if that's not the case today.<br></blockquote><div><br></div><div>But that doesn't mean you can't apply it in parallel. We've had great success using a MapReduce over ~100MLOC code to do very fast parallel static analysis.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you mean make doesn't compile in parallel when it could, I would be<br>
interested to see an example, because afaik that's a solved problem<br>
theoretically.<br>
<div class="im"><br>
> It seems to me like most innovations look like this at first. I might<br>
> be wrong, but at least let me try ;)<br>
<br>
</div>Nothing against you trying; I'm hoping at least one of us will learn<br>
something.  :-)<br>
<br>
You may have heard, "Scientists stand on one another's shoulders;<br>
computer scientists stand on one another's toes."  A lot of innovations<br>
aren't, and it's not hard to find projects (and products) re-solving<br>
things using new terminology, seemingly unaware how old and well trod<br>
is the ground they're covering.  It pays to be skeptical.<br></blockquote><div><br></div><div>Well, obviously I think I am skeptical myself, but I'm aware that's confirmation bias ;)</div><div><br></div><div>
Cheers,</div><div>/Manuel</div><div><br></div></div>