tree f094107d1e05a2a0648ca1db3bfd66ba0e5a97bb
parent 2d9fd62c6572e324ae893e2c5bc2f054b7f70fa4
author RJ Ascani <rjascani@google.com> 1603151411 -0700
committer Commit Bot <commit-bot@chromium.org> 1607707037 +0000

Restat build.ninja after gen

As of version 1.8, ninja caches mtimes in the .ninja_log file and will
not restat a file if it has an entry in the .ninja_log. This becomes
problematic for generator files such as build.ninja. In a scenario where
the .ninja_log has an entry for build.ninja (ie, after ninja has had to
trigger a re-gen) and a manual run of of `gn gen` has updated the
build.ninja file, a subsequent invocation of ninja will trigger yet
another re-gen of build.ninja.

This can be reproduced like this:

  # Initial build
  gn gen out && ninja -C out
  # Trigger ninja re-gen so there's a build.ninja log entry
  touch BUILD.gn && ninja -C out
  # Manual re-gen
  gn gen out
  # The following command will re-gen again before building
  ninja -C out

To work around this, the recommended approach from ninja is to use the
ninja restat tool to get ninja to update the mtime in the .ninja_log.
This CL does that by attempting to invoke `ninja -t restat build.ninja`
immediately after the build.ninja is generated by `gn gen`. Because this
tool was only introduced in 1.10, the usage is gated on having a ninja
binary of at least that version. The ninja binary can be provided via
the --ninja-executable switch.

Bug: 136
Change-Id: If40391aa13e6ef71c4e8ab26aff57d66a8137b8e
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/10400
Commit-Queue: RJ Ascani <rjascani@google.com>
Reviewed-by: Brett Wilson <brettw@chromium.org>