Even if such a target is dirty (i.e. the file does not exist), it has nothing to do, which makes it safe to mark as outputs-ready. Without this change, ninja will print no output when rebuilding the target (or an order-only dependency thereof), instead of reporting it has "no work to do".
Specifically, only delete if the file was modified or if the rule uses a depfile. Fixes issue #226.
This test covers bug fix introduced by 62e9139. However, reverting this patch does not trigger a test failure. Maybe, I am not testing on the right platform (Linux). Anyway, in all cases I think this test deserves to be added.
From a patch from Peter Kuemmel <firstname.lastname@example.org>.
… we do Previously, if a command fails, the fate of the other child processes running in parallel was inadequately controlled. On POSIX platforms, the processes were orphaned. Normally they would run to completion, but were liable to being killed by a SIGPIPE. On Windows, the child processes would terminate with the parent. The cleanup-on-interrupt patch caused the SubprocessSet and Builder destructors to clean up after themselves by killing any running child processes and deleting their output files, making the behaviour more predictable and consistent across platforms. If the build is interrupted by the user, this is correct behaviour. But in the case where the build is stopped by a failed command, this would be inconsistent with user expectations. In the latter case, we now let any remaining child processes run to completion before leaving the main loop in Builder::Build.