Subject: Re: remote job execution with make
To: Frederick Bruckman <email@example.com>
From: Dave Sainty <firstname.lastname@example.org>
Date: 01/03/2000 13:14:24
Frederick Bruckman writes:
> Some of the problems with NFS are already exposed, and oozing, like if
> one of the machines is a lousy timekeeper, "make" will get sorely
> confused. What would be really neat would be to export jobs with "rsh"
> or "ssh". Consider that most of the cross-compilers and assemblers
> already work; it's only the cross-linker that's a work in progess. So
> you could configure and link on the target host, but do all the slow
> stuff in-between on fast machines.
Hmmm, I used to do this, but it didn't require any "make" changes. I
simply defined CC as a script that farmed (rsh) the tasks out and used
a multi-job version of make (gmake -j<x>, I think).
This probably worked because the machines were well synchronised, but
I imagine if the script touch(1)ed the files after completion on the
same machine as the make(1) process runs on, it would probably work
fine too even with poor synchronisation.
The overheads of that particular scheme are bound to be too high to
make it worthwhile on modern machines. The target environment in my
case was a network of slow and heavily loaded Suns. It was beneficial
just having the task of locating the currently least-loaded machine
abstracted away :)