On 5 Feb 2007, at 18:47, Eric Wilhelm wrote:
From my reading, distcc only ships a single pre-processed file across
the wire and gets a binary back from the cc on the other end.
That's a
very simple and easy to distribute scheme, and I think the claim is
that it will work in any build as a drop-in replacement for cc.
Yup - it still runs gcc -E on the main build machine to pre-
process source.
A similar scheme might work instead of the rsync (or nfs?) full-mirror
that I suggested, but it would basically mean shipping the entire
dependency tree across the wire, plus whatever arbitrary data might be
needed. I think this means it is best to setup the delegate boxen
beforehand. Either way, I'm not sure it really needs a different test
execution and reporting scheme than a locally parallelized build.
I'm not sure. Maybe I'm missing your point.
To run tests locally you need to
* launch the tests in // and gather their output
* display the test progress / results differently
* make it possible to attach some metadata to tests
that describes such things as which tests can safely
be run concurrently with which other tests.
Distributing tests among multiple boxes requires all those things but
potentially there's a lot more marshalling to be done to create a sane
test environment on each box. It's a much bigger problem I think.
--
Andy Armstrong, hexten.net
