On Mon 2003-08-25, Dag Wieers wrote: > Well, at the end of compiling the set of objects (either the end of > that parallelization or when -j5 was given, after the 5th job).
What set of objects? Make does not tell distcc the list of targets that will be built or the -j level. > > One can imagine a naive algorithm wasting a lot of time. > > > > To turn the question around: why don't we just schedule the job on > > the nearby machine in the first place? > > Because it may make configuring complex (define what machine is nearby > and what not) and a configuration may be static while the environment > is changing a lot (read: I could be moving from offices). But re-queueing the job on a nearby machine seems to require this same knowledge too. > If we could test the latency of the network and the 'power' of each > system before compiling and have a some clever logic for deciding > which systems to use in what order, it would be even better. Because > there's no additional configuring involved and it would work with > dynamic set-ups. I think I'd like it to gain information about the speed of machines as it goes along. Perhaps that would allow it to sort the machines into a different order, or perhaps have stronger preferences between machines than it does at the moment. -- Martin __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc