On Mon, 2018-10-22 at 13:19 +0000, Richa Bindra wrote: > Just wondering if anyone is interested in the proposed patch?
I have no problem with having a mode or method of causing the entire build to fail quickly whenever the first job fails. However, whatever method that is has to be complete and work in all situations, including recursive make, and needs a way to stop all child processes before exiting so they don't continue to run after make exits. And any new feature like this needs to have tests available. I'm not suggesting that any one person needs to do all this, I'm just explaining why I've not applied the proposed changes, as they are not complete. For this particular change, is there a good justification for allowing some number of errors before failing? In what situation would you want to keep going after three errors, but fail if you hit a fourth (for example)? I'm not sure I see the need for that feature. In my opinion these are the two important enhancements: One: if a failure happens somewhere in the build stop processing cleanly as soon as possible... by that I mean, allow running jobs to complete but don't start any new jobs. This is how the build works today BUT it is not distributed across recursive invocations. That should be fixed and this should be the default behavior (if -k is not given of course). Two: if a failure happens somewhere in the build stop processing immediately... by this I mean, kill all currently running child jobs and exit right away. There can be some extra option to enable this behavior. We will probably want to consider deleting the target files for any jobs we kill... that will need consideration. Not all recipes or tools will be careful to do things like write to temporary files and atomically rename once the file is complete. _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make
