tree 8444e17479672dac61e47f1b7274ea7db47f723a
parent 519b720aa0e0b620ba4111ab48e60c2e37f1d6d6
author Bryan Henry <bryanhenry@google.com> 1656138344 -0700
committer Brett Wilson <brettw@chromium.org> 1659740424 +0000

[gn] Prevent build.ninja deletion when regeneration is interrupted

Prior to this change, the top-level build.ninja file generated by GN
was configured in such a way that interrupting ninja file regeneration
(e.g. with Ctrl-C) would cause ninja to delete build.ninja. This was
done by ninja's Builder::Cleanup() function because the "build
build.ninja" statement that GN produces uses a depfile argument. GN uses
this depfile to capture implicit dependencies and automatically trigger
ninja regeneration if, for example, any BUILD.gn source file is
modified.

If build.ninja is deleted for this reason, the user must manually run
`gn gen` to recreate it; a poor user experience. Worse, command-line
arguments that the user previously passed to `gn gen` are also lost,
meaning that the user must be sure to pass the same arguments again.
Because of this bug, developer tools layered on top of GN (like
Pigweed's `pw watch` file watcher) have added handling to automatically
run `gn gen` for the user in an attempt to provide a smoother user
experience, but these attempts are still frustrated by the command-line
argument loss.

This change modifies the flow of ninja file generation slightly such
that build.ninja should never be deleted, even if regeneration is
interrupted, and thus ninja should always be able to restart it. The
build rule for build.ninja has been split in two so that ninja will
only delete the .tmp file if interrupted:

  build build.ninja.stamp: gn
    depfile = build.ninja.d

  build build.ninja: phony build.ninja.stamp
    generator = 1

`gn gen` now does the following:

  1. If the '--regeneration' flag is present (i.e. if the caller is
     ninja rather than a user), the 'build.ninja' file is truncated to
     only the commands needed to initiate regeneration again. (This is
     the same operation `gn clean` applies to 'build.ninja'.)

  2. Ninja file generation proceeds as before, writing 'build.ninja' and
     'build.ninja.d', plus a new 'build.ninja.stamp' file.

Essentially, this works by misleading ninja about when 'build.ninja' is
actually written. Importantly, because of this gn takes on the
responsibility for ensuring that 'build.ninja' is always valid, which it
achieves through atomic writes.

Fixed: https://bugs.chromium.org/p/gn/issues/detail?id=25
Change-Id: I4aef0317466b5e3430a9ef44eaa63c9515afefab
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/14200
Reviewed-by: Brett Wilson <brettw@chromium.org>