Re: proposal: stop_at_err_count patch

[Paul Smith]

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.