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
running":
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!
Thanks.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?41781>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
