Subject: Re: make: adding .KILL ?
To: None <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 11/01/2006 03:43:12
In article <20061031224157.CB710A3ED@zen.crufty.net>,
Simon J. Gerraty <firstname.lastname@example.org> 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
I don't like the SIGKILL and I don't understand the reason for the sleep()s