Changes

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.

In keeping The project has been focused on getting distcc to work with the true open-source traditionMozilla, this 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 will be incomplete and in sub-standard qualityfor others who might wish to [[Adding Compilers to Distcc|add support to distcc for other compilers]] (e.g., Java, C#, etc.). 

==Dec 6, 2006==The major bug right now is Preliminary examination indicates that compiled object files donthis won't come back :(be so much work. This will The functions seem to already be fixed soon. Really. We promisethere.

==Nov 29March 19, 20062007 ==We have finally finished a big part of our project - the functionality! Now we are in the process of testing. Inital tests were somewhat positive. We still need to debug certain problems in the patch. It will probably be finished after the semester is over. If anyone is still interested in the project and wants to help out, we still are interested in getting the results reproduced by average users.

There was a subtle bug in Mozilla's code base that [https://bugzilla.mozilla.org/show_bug.cgi?id==Nov 22374563 bug 274563] deals with that made it impossible for distcc to build Moz. If you apply the patch attached to the [https://bugzilla.mozilla.org/show_bug. 2006cgi?id==We are down 374563 bug] then you'll be able to our last 3 functionsdo distcc builds of Mozilla. We hope will soon be releasing our first beta to have test cases done so we can really start testing out reflect our confidence in the whole application and try it with the two machines we do havecode.

==Nov 6. 2006Feb 27, 2007==There is a scheduled 'hack day' being set up. Were putting it at every tuesday at around 5:20 in the TEL open lab.

==Nov 2. 2006==After a haitus from touching distcc, we battled the serpent We are able to do distributed builds of the C Mozilla but it dies when trying to link stuff together (hahaissues surrounding ATL?) once again . So in order to take advantage of Ben Smedberg's wonderful [http://benjamin.smedbergs.us/blog/2007-01-12/mozillabuild-rc1/ Mozilla Build] and be able to get help figuring out weird linkage bugs and retreated dependancies without having to deal with our lives, barely, but lost our ego and motivation cygwin issues (at least Cesar didwhich are galore). We cleared up , we've started a path setting bug that caused CL to die and return branch with a bad return valuemingw port: svn://cdot. Then we (eventually) passed ParseHost case, which parses an environment variable for ip addresses and domain namessenecac. A inproperly done svn merge wasted a good few hours on that.ca/distcc/branches/mingwcompatible/

We also created safeguards==Jan 4, so 2007==The post made to the build newgroup seems to have gathered dust. If mozilla is limited to only 4 jobs, than distcc is somewhat limited. But that any unimplemented vtable function that is called will throw an error message instead of having a segmentation fault's not our problem.

==Oct 20Tom has found one problem with using cygwin. 2006==Using absolute pathnames. For example :<code><pre>We have a usable windows box $ cl hello.cMicrosoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for doing our msvc testing 80x86Copyright (finally!C)Microsoft Corporation. Thanks to [[User:Bhearsum]] for the boxes All rights reserved.

==Oct 12hello. 2006==cArgh. I have been trying to build firefox using distcc for about 2 weeks, with many small details getting in the way. At one point things were working, but than it stopped and I don't know why. I finally, at one point, got things to build on andrew's machine. But the build failed complaining about (this is one of the many, many things) ''undefined reference operator deleteMicrosoft (void*R)''. I think it might be because distcc is calling gcc rather than c++. I changed the MOZCONFIG to use CC='distcc gcc' and CXX='distcc g++'Incremental Linker Version 8. This threw me this ugliness : make[1]: warning: jobserver unavailable: using -j100. Add `+' to parent make rule50727.42Which I told reed about, but has never came across this problemCopyright (C) Microsoft Corporation. One nasty solution is to use -j without specifing a number to allow unlimited jobs. At least it's workingAll rights reserved.

In other news, Tom sent a [http/out:hello.exehello.obj</pre></listscode>Works.samba.orgBut this doesn't :<code><pre>$ cl /cygdrive/c/archivehome/distcctemp/2006q4hello.cMicrosoft (R) 32-bit C/003466C++ Optimizing Compiler Version 14.00.50727.42 for 80x86Copyright (C) Microsoft Corporation.html patch] All rights reserved.

== Oct. 2 2006 ==cl : Command line warning D9002 : ignoring unknown option '/cygdrive/c/home/tempA preliminary test of running distcc in cygwin revealed we were failing 4 tests; one or two more than our first patch/hello. We tried to fix it, but never had success and didnc't issue cl : Command line error D8003 : missing source filename</pre></code>There are a commit. A while later few things we try running distcc again on another machine. This time we were only failing one test, which is less than our first patch. Here is the known tests to failcan do about this :# EmptySource_Case --- This is expected to fail since this is a bug in the earlier gcc compiler.* replace /cygdrive/c/ with C:\The explination for the extra three preliminary tests failing is because we interupted one of * user must replace the tests, enviroment variable TMPDIR which we believed caused the daemon defaults to be orphaned and exacting it's revenge on the murder's of it's parent processes./tmp

== SeptCesar found another problem. 26 2006 ==Tried Both C/C++ preprocessed file ends in .i. cl has no way of knowning if it's a C/C++ preprocessed file. So it refuses to do parallel builds with mozilla in linux compile it (maybe it treats it as an object file). So when we preprocess, we should have done this first)to redirect to the same extension as the source file.<code><pre>$ cl hello. Here is something usefull to know :iTo parallel build in mozilla, you cannot pass the Microsoft (R) 32-jN option to make and expect it to workbit C/C++ Optimizing Compiler Version 14.00.50727. It didn't 42 for me, and make was killing itself without an explination80x86Copyright (C) Microsoft Corporation. I later learned that you have to add the following line to mozconfig mk_add_options MOZ_MAKE_FLAGS=-j8All rights reserved.

== Septcl : Command line warning D9024 : unrecognized source file type 'hello.i', object file assumedMicrosoft (R) Incremental Linker Version 8.00.50727.42Copyright (C) Microsoft Corporation. All rights reserved. 24 2006 ==

We think we've got the architecture right now. Ofcourse the only way to know is to start porting cl /out:)hello. We're now going to try to port the tests to work with clexehello.exeihello.i : fatal error LNK1107: invalid or corrupt file: cannot read at 0xEE7F</pre></code>