In article <20061031224157.CB710A3ED@zen.crufty.net>,
Simon J. Gerraty <sjg@crufty.net> wrote:
>Some time ago, David wrote:
>>Given the changes I've made recently in order to get parallel makes to
>>stop in a finite time when an error happens on one branch, I suspect
>>that a merge in either direction will be painful.
>
>Those changes work nicely btw, but there is still the issue that a job
>with _long_ running sub-jobs, won't notice the failure in the other branch
>until its sub-jobs finish.  I see this in part of my build at work where
>a big chunk of the tree is built using gmake.  All the bmake jobs stop
>immediately one of them fails, but the gmake bit chugs on and on...
>
>So, I thought of adding a .KILL special target - to mean, if this job 
>fails - kill everyone left standing.  Which does the job nicely ;-)
>
>The patch below is against bmake as of July, since with the recent churn
>in make, I'm no longer able to build it by itself on my NetBSD boxes,
>which also means I can't plan to update bmake.
>
>It seems the MAKE_NATIVE define has grown to mean something like __NetBSD__
>native build, which is not what it used to mean, and I'm currently at a
>loss as to how to fix it.  The emalloc stuff is the main issue I think.
>
>Anyway, what do you think of the following idea (could likely use 
>some tweaking):
>

I don't like the SIGKILL and I don't understand the reason for the sleep()s

christos