<br><br><div class="gmail_quote">2008/7/11 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 4:56 PM, Csaba Hruska 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;">
This looks for me a completly different project called: integrating clang preprocessor to (original)  distcc because except the used preprocessor remains the original (command line options, network protocol and the whole functionality). This is not bad but i dont think that this is the primary task of this project. In my opinion the main goal to make as fast and scalable and portable(support crosscompialtion) compiler as we can using clang.<br>

</blockquote>
<br></div>
Of course our interest is making a great distcc for clang.  My main meta-point was that by supporting other compilers for subtasks of the compilation work you can stage more of the implementation without relying on everything in Clang to be working perfectly.  And despite Argiris great work on C++ parsing, full support for C++ compilation is a long way off, so supporting other compilers for this task might be a huge win for adoption of a new distcc.<br>

<br>
Also, it's better to get measurements early on where the performance issues are because that effects fundamental aspects of the design.  A rapid evolution of the distcc design with testing and real numbers will not only make the new distcc both faster and more scalable (per your goals) but also potentially more stable and usable at an earlier stage.<br>

</blockquote></div>I agree that benchmarking is important to find the weak design points and I'm also curious about performance results. I'll do some benchmark after when i finish the astconsumer lib and get the new driver code.  My main problem is that I cant imagine how we can support external compilers without messing up the current design and without reimplement the original distcc. Distributed clang server's goal is support compilation natively without executing external programs. Or if you think to support the client side, (new clang distcc client with original distcc server case) then we have to reimplement distcc's protocol, including ssl support. In this case its far much easy to patch the original distcc client to include and use clang's preprocessor natively.<br>
I'd like to focus on clang specific stuff. Ex: I can imagine an AST mege function what can support precompiled headers, or can be used to store the already parsed and semachecked headers and reuse it later from a Database. This means one file (header) is parsed and semantically checked only one time.<br>
<br>