[Cook] Distcc and Cook

[Simon Clift]

On Tue, 2005-02-15 at 11:03 -0600, Jerry Pendergraft wrote:
> cook_rsh is very much more than a wrapper. It negotiates 
> remote command capabilities, loads etc and balances jobs
> over a network of machines.

Please don't think I'm being dismissive about cook_rsh; I
did have a peruse of the code for ideas beforehand.  I'm
just planning a different approach: hog resources without
shame since nobody was using our multi-cpu box. :-)

DistCC does a bit of load balancing, I think.  At least you
can limit the number of slots it uses on each machine.  I'm
just experimenting at this point.

> > DistCC pulls together what the compilation needs,
> Do you really mean "gets everything needed"?

I think/thought so.  Having said that I hit some trouble
with GCC 2.95.0 on the multi-cpu box and the C++ Boost
template library.  The 2.95.0 C++ headers got into an
argument with the Boost templates, which had been set up
using gcc 3.4.2.  My understanding is that distcc uses local
headers where it believes this is possible.

> Seems like that could take longer than the actual compile.

That's distinctly possible.  I'm just trying to get a feel
for it.  The sys admins here have not moved on my request
for an NFS mount to the big box for 2 months now.  Hence I
was looking for an alternative approach to use the resource.
For a room full of well-connected, otherwise idle boxes it's
probably ideal.

The good news is that plain parallel cook works with DistCC.
My problems now seem just to be DistCC itself.

Now all I need is parallel aegis -test -regression  :-)

> Plus, considering includes etc be very tricky.

C++ STL-style templates being the worst case here.

> And, of course, would not deal with multi-architecture
> needs which actually requires the remote machine be of the
> required architecture.

The DistCC people claim that cross-compilation isn't a
problem, you just need to have the right compiler switches
set... My biggest arch difference is Athlon-XP versus
Pentium versus Xeon, so it's not a (very) big issue for me.

-- 
Simon Clift                        ssclift at math dot uwaterloo dot ca
Ph.D. Student, Computational Finance
Scientific Computing Group, School of Computer Science
University of Waterloo
Waterloo, Ontario, Canada   N2L 3G1