<br><br><div class="gmail_quote">2008/7/10 Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On Jul 10, 2008, at 9:53 AM, Chris Lattner wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

There is one more requirement if we follow this. Most of<br>
ASTConsumers have one output stream or file, but there is<br>
StaticAnalysis what is make a couple of HTML files and because<br>
distcc static analysis is a big speedup, we must support this<br>
astconsumer, so we have to capture its output somehow.<br>
</blockquote>
<br>
I would worry about this one later.  I think it would be good to focus<br>
on distributing the other ASTConsumers before the static analysis one.<br>
</blockquote>
<br></div>
I think the solution for the AnalysisConsumer is two steps:<br>
<br>
1) Factor out the creation of the HTMLDiagnostics object used for HTML rendering out of AnalysisConsumer.  Instead, the ctor for AnalysisConsumer takes a PathDiagnosticClient* (which in the regular driver is an HTMLDiagnostics object).  I planned on doing this anyway.<br>

<br>
2) In the distcc client, instead of creating an HTMLDiagnostics object, create a different PathDiagnosticClient object that just batches the diagnostics (this doesn't exist yet, but is easy to implement).  The distcc client can then send the diagnostics back to the original client, and not have to worry about HTML rendering.<br>

<br>
There will also probably be some ugly details, but ultimately the distcc client shouldn't care how the final analysis results are consumed by the end-user.<br>
</blockquote></div>Right.<br>I've started working on putting all reusable thing from Driver directory into a separated library called driver. (in my opinion every app's dir name should be same as app name. clang (ordinary local driver), distclangserver(distcc server), distclang(distcc client)). The dist app names should be more simple if anyone can suggest greatet descriptive names. :)<br>
About supporting other compilers by distributed clang: Ted, please describe you ideas, because i have no idea what's the point of this thing.<br><br>I'd like to put these things into the driver lib: almost everything from Driver dir and some functions from clang.cpp.<br>
<br><br>