[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #41781] Provide a fast fail path when a target is compromized durin
[bug #41781] Provide a fast fail path when a target is compromized during a parallel build
Mon, 28 Apr 2014 14:46:58 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0
Follow-up Comment #2, bug #41781 (project make):
Hi Paul. Thanks for the clarifications. I do not use recursive make, I have
one makefile and one DAG (I read the recursive make considered harmful paper),
but I understand that for completeness it should be covered.
Finding the source of the failure that caused all the other targets to abort
is not obvious. My users were struggling with this when I was usign that
patch. Perhaps a different error message for the jobs that were aborted vs.
the job that caused the abortion could help sort things out in
post-processing. Could it be a different exit code? I think if someone
actively choses to use a fast fail option, they may be willing to accept some
amount of unpleasant aspects.
"This means that make will still not kill any existing jobs that are
I would like to have an option that causes Make to kill all jobs in flight as
soon as one of the targets has failed because it does save people time. A
worst case scenario that comes to mind is the Friday afternoon frenzy when
there are 20 integration builds on the CI server queue. People are trying to
get new code accepted for the long weekend regression tests for a Monday
morning delivery. They are eager to get home. And then Make waits for all
parallel in-flight jobs to complete despite an earlier failure in one of the
parallel jobs in the build at the head of the integration queue, and the admin
who can kill this build from outside Make is away.
I wish I had spent more time learning GNU Make's source code!
Reply to this item at:
Message sent via/by Savannah
|[Prev in Thread]
||[Next in Thread]|
- [bug #41781] Provide a fast fail path when a target is compromized during a parallel build,