| commit | eb6c1cdb0d2ea3e5a3fdbd9ca2ef5941235c2c36 | [log] [tgz] |
|---|---|---|
| author | David 'Digit' Turner <digit@google.com> | Tue Oct 31 17:26:50 2023 +0100 |
| committer | CQ Bot <fuchsia-internal-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Jan 26 19:55:04 2024 +0000 |
| tree | ef2791c8eddf4e5b42810048a6f0064c209453df | |
| parent | 8360dcab82d40f3f37ba747f72f35d86f1a67e4c [diff] |
Track and remove dynamic implicit dependencies Due to `deps_loaded_` being reset to false unconditionally in Edge::Reset(), every incremental build reloaded dependencies from the deps log or dep files, and added them back to the build graph. This resulted in massive and un-necessary duplications. For example, for a large Fuchsia build plan, every no-op incremental build would add 200 to 300 MiB of memory to the RSS of the persistent server process! This patch fixes the situation by doing the following: - Do not reset `deps_loaded_` in Edge::Reset(), i.e. the dependency information recorded in each Edge stays there and will not be reloaded by default. - Add `static_implicit_deps_` and `static_implicit_outs_` fields to track the number of implicit dependencies that were added to a given Edge, through the deps log, depfile or dyndep loading. And implement a new Edge::RemoveDynamicImplicitDeps() method to remove them when needed. + Add a unit-test to verify that this mechanism works properly. This patch has three benefits: - It fixes the correctness issue from bug 135792 (verified with a new unit-test). - It fixes the memory leak from bug 135951 (verified manually, the RSS is stable after two no-op builds, and only increases very slightly between the first build and the second one). - It speeds up dependency scanning for the next incremental build significantly (2s -> 1.5s) because it no longer needs to reload *all* recorded dependencies from the log on each edge it visits. + Add new dyndep-related unit-test to check the behavior of the new code. Fuchsia-Topic: persistent-mode Original-Change-Id: I09b5035fd7869a6031898707c67bbd0e3cf0d452 Original-Change-Id: Id6142b6834e78ab27eb7c94954849ce1d0872350 Change-Id: Iadcdbb64e28815bcec71edc530c829fcfb3ff20f Reviewed-on: https://fuchsia-review.googlesource.com/c/third_party/github.com/ninja-build/ninja/+/978773 Reviewed-by: David Fang <fangism@google.com> Commit-Queue: David Turner <digit@google.com>
Ninja is a small build system with a focus on speed. https://ninja-build.org/
See the manual or doc/manual.asciidoc included in the distribution for background and more details.
Binaries for Linux, Mac and Windows are available on GitHub. Run ./ninja -h for Ninja help.
Installation is not necessary because the only required file is the resulting ninja binary. However, to enable features like Bash completion and Emacs and Vim editing modes, some files in misc/ must be copied to appropriate locations.
If you're interested in making changes to Ninja, read CONTRIBUTING.md first.
You can either build Ninja via the custom generator script written in Python or via CMake. For more details see the wiki.
./configure.py --bootstrap
This will generate the ninja binary and a build.ninja file you can now use to build Ninja with itself.
cmake -Bbuild-cmake cmake --build build-cmake
The ninja binary will now be inside the build-cmake directory (you can choose any other name you like).
To run the unit tests:
./build-cmake/ninja_test