[http://distcc.samba.org/| distcc], distributed compilations for C/C++ compilers.

The goal of this project is to speed up Windows Mozilla Builds by spreading object compilations over several machines. This can be done by using an open source product called distcc created by Martin Pool. Unfortunately this is only available on *nix machines using gcc. Our project involves porting this software to Windows and use [http://msdn.microsoft.com/visualc/ Microsoft's Visual C++ compiler] using cygwinand msys.

None yet We have stuff for you to do! * [http://www.daveliebreich.com/blog/ Dave Liebreich] - Thanks for checkin whether cygwin's ln will create working links to cl.exe (e.g. a link name clfoo.exe to cl.exe).* [[User:Bhearsum|Ben Hearsum]] - for the windows box and support! Thank you!* [[User:JasonSpiro|Jason Spiro]] - For helping figure out why cl wouldn't execute in the unit testing framework and assisting in finding the right path to solve this issue.* [[User:Pcvitori | Phil]] - helped with changing the page on helping people do research into cl options for us.* Moe* [[User:RealMarkP|Mark P. (aka RealMarkP)]]* David Humphrey* Jeff* Melz = Product Documentation =The project has been focused on getting distcc to work with Mozilla, mainly because Mozilla uses GNU Makefiles which can run concurrent jobs. We have started a [[distcc_mozilla_tutorial| tutorial]] in order to help testers/developers. We have also written documentation for others who might wish to [[Adding Compilers to Distcc|add support to distcc for other compilers]] (e.g., Java, C#, etc.). == Current Status ==* Some of the Test Cases may be incorrect. Neither Tom nor Cesar have extensive experience in CL options. So it may not distribute when it should, or it may distribute when it shouldn't. == What's still to do == <!-- Taken from ben's project page --><table style="width: 100%;" class="standard-table" cellborder=1 border=1 cellpadding=2 cellspacing=0> <tr><th>Task</th><th style="width: 10%>Priority</th><th style="width: 30%">Status</th></tr> <tr><td>Fix documentation, including website, manpage, and tutorials</td><td style="background-color: #ff671e; text-align: center; font-weight: bold; font-size: bigger">Medium</td><td>Neglected. I think Tom has worked on the man page, Cesar has worked on the tutorial</td></tr> <tr><td>* find a suitable replacement for fork()** using windows threads. Need to use #ifdef directives to switch between unix fork and threads. But perhaps where is a better way to do this.** Perhaps talk to Martian Pool to see if he has any ideas? He hasn't been in the mailing list for a while.</td><td style="background-color: red; text-align: center; font-weight: bold; font-size: bigger">High</td><td>Have not started</td></tr> <tr><td>* Send .pdb files to allow debug builds. Currently blocking mozilla from ever using distcc.** looking at the protocol. Hopefully we don't have stuff to changed a lot.</td><td style="background-color: red; text-align: center; font-weight: bold; font-size: bigger">High</td><td>Have not started</td></tr> <tr><td>* Port distcc to use mingw** Properly link in winsock library ([http://www.foobartastic.com/2007/02/27/distcc-alpha-2-and-moving-to-mingw/ fixed] using libtool)** use windows threads (another high priority item)** locate and replace unix functionality that existed in cygwin, but doesn't exist in mingw.</td><td style="background-color: red; text-align: center; font-weight: bold; font-size: bigger">High</td><td>Have only got libtool to compile a simple sockets program. We have now port it to distcc* probably use #ifdef MINGW ... #else ... #endif in source files that use socket.h* another possibility is to have one header file handle this, and the source files include that header file </td></tr> <tr><td>Find more applications that use the Makefile system and can use CL</td><td style="background-color: #ff671e; text-align: center; font-weight: bold; font-size: bigger">Medium</td><td>Difficult to find. Not many open source applications use Makefile and MSVC, many choosing to opt for NMake</td></tr> <tr><td>Compile NSPR using distcc</td><td style="background-color: #ff671e; text-align: center; font-weight: bold; font-size: bigger">Medium</td><td>Dave suggested only building NSPR because its smaller and won't take as long to compile. Cesar is responsible for this</td></tr> <tr><td>boy there sure are lot of memory leaks... would be nice to fix that</td><td style="background-color: yellow; text-align: center; font-weight: bold; font-size: bigger">Low</td><td>We can use tools like valgrind and mtrace to help. Or we can use Boehm-GC to free the memory automatically. But this is a lot of work for such low priority.</td></tr> <tr><td>Make sure that there are no orphan distcc processes left after make maintainer-check</td><td style="background-color: yellow; text-align: center; font-weight: bold; font-size: bigger">Low</td><td>This is a problem when tests are killed, and can leave to false-negatives when you try to rerun the tests again. But that can be fixed with god ol' kill-y mc. kill, agent 009</td></tr> </table> <!-- {|class="standard-table" border='1'|-| Need to port unit tests to ensure same functionality for cl as for gcc. | medium |-| <strike>Get distcc working with Moz </strike> {| class="standard-table" border='1' |- | <strike>check why MSVC Preprocessor seems to be dying with firefox 2.0 release source. Possible Solution: We're doing unix to windows path conversion on the daemon, move that code to the client and everything might be good.</strike> | <strike>high (currently Cesar & Tom)</strike> |- | <strike>Figure out why distributed builds die but nondistributed builds don't. This issue lies in the Moz Build System not in distcc code.</strike> | <strike>High</strike> |}| <strike>HIGH</strike>|-| Get a list of programs that work with our distcc{| class="standard-table" border='1' | Application | Reporter |- | [http://cdot.senecac.on.ca/software/nled/ NLED] | Cesar |- | [http://www.mozilla.org mozilla] | Tom + Cesar |}|Medium|-|boy there sure are lot of memory leaks... would be nice to fix that| low|-|Make sure that there are no orphan distcc processes left after make maintainer-check| low|-|}--> == How to get distcc to compile use cl == Tom and Cesar created this patch keeping backwards compatibility in mind. You should be able to still use distcc to compile your c programs if you wish. But if you applied the patch, you probably want to do!more than that. Firstly, the environment variables for distributing with cl is different. '''DISTCC_HOSTS''' is still valid for gcc, but cl will be looking for '''DISCC_CL_HOSTS''' instead. In fact, that is the only thing it looks for. Unlike gcc, cl will not look for ~/.distcc directory. This might be implemented later on. Secondly, masquerade mode works only for gcc. If you want want to use cl, you must explicitly say so (distcc cl hello.c). If you are using gnu make, you must also explictly tell it to use cl as well (eg using CC, CXX, etc). == Maintainer-check ==  ''NOTE :: If you run the checks, please check your processes (ps aux, or the task manager) for leaked distcc/distccd programs. We will fix this ASAP'' You may ignore this section if you installed Microsoft's CL in the default C:\ directory and your tests work fine. In order to properly run the tests, you <u>may</u> need to make a few changes. The '''PATH''' variable is reinitalized when the test cases are run. Normally, the tests ''will'' fail when they try the cl tests. This is because PATH does not look for the cl executable and the libraries. Tom and Cesar have made certain assemptions when extending the include path, and included these following paths : /cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/bin<br>/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE If it is different for your machine, you need to find these in the Makefile.in or Makefile and change them to your settings. == Extending the program ==This will be postponed until we get distcc working properly (not fully)with cl.

For the most up to date info look up [http/out:hello.exehello.ihello.i : fatal error LNK1107: invalid or corrupt file: cannot read at 0xEE7F</pre></www.foobartastic.com foobartastic]code>