-jobs parameter in tinderbuild

[Ade Lovett]

On Aug 1, 2008, at 14:22 , Dmitry Morozovsky wrote:
> On Fri, 1 Aug 2008, Joe Marcus Clarke wrote:
> JMC> It's still a valid argument in Tinderbox 3.0, though it is  
> broken.  I'll
> JMC> look at removing it for Beta 3.
>
> BTW - what should be done to revive this option? For now, multi-core  
> (2,
> or ever 4) systems are rather usual, and cheap, and there is usually  
> only one
> or two builds for which one would want to have package sets for...

It's somewhat non-trivial in all but the simplest cases (ie: a couple  
of port builds that have no overlap).

Imagine a case where you have two builds, A and B, both of which  
depend on C (and possibly a bunch of others which haven't been built  
yet, ie: they may not get to 'C' at the same time).

You then run the risk of 'C' being attempted to be built by two  
independent tasks at the same time, with all the hilarity that that  
causes.

Now that we have an actual dependency table, I have been toying in the  
back of my mind to replace the current Makefile-based system with one  
that uses that table, but that's an awful lot of work (read - 3.1 at  
the very least).  Use of this table may also be the way forward to do  
distributed builds (and there's nothing to say that 'distributed' in  
this sense couldn't mean two or more builds running on the same  
machine -- we'd just have to get away from using the TB buildname as  
the prefix under which everything sits).

This is all pretty complex, however.  As such, I think it's  
unrealistic to do anything but kill off the -jobs option for 3.0, get  
it released, fix up any remaining bugs for a 3.1 (or 3.0.1, or  
whatever), and then start some serious discussion on where to go next.

-aDe