Subject: Re: make: adding .KILL ?
To: None <>
From: Christos Zoulas <>
List: tech-toolchain
Date: 11/01/2006 03:43:12
In article <>,
Simon J. Gerraty <> 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