-jobs parameter in tinderbuild
ade at FreeBSD.org
Fri Aug 1 17:37:58 EDT 2008
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
> 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
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.
More information about the tinderbox-list