>> I don't think that these things need to be, or should be, exclusive of one
>> another. That'd definitely the wrong idea.
>
> Hmm, sure. I'm just saying that implementing multiple-job-build for
> individual packages gives more benefit - so IMHO that should be pursued
> first.

Adding the -j options is a good thing; I'm already running a bulk build 
using that on an SMP machine to see what breaks. It's a good start. 
However, my SMP machine here is terribly slow (dual 50 MHz SPARCs in a 
SPARCstation 10). If someone wants to get a faster MP machine going, 
that'd be a good test. I have a dual 1.8 GHz G4 accelerator which I'll try 
soon if nobody beats me to it.

But a method of splitting off makes in various non-interdependent packages 
wouldn't be hard, nor would it take away from -j builds. Obviously, if one 
tells a machine to do both, the multiple builds will help ensure that all 
of the processors are in use (the -j thing obviously won't assure that), 
with the slight risk of getting bound on disk I/O if the system is 
sufficiently fast in relation to the disks.

Does anyone have some good ideas about how to use a dependency tree to do 
this? I'll give it a look - it'd be easy to do the stuff at the ends of 
the tree, since they won't have dependencies and will just be dependencies 
themselves, but I'm not clear about an efficient way to do stuff higher up 
while properly avoiding interdependencies. Ideas?

John