StatusTable: Fix build timestamp handling. Ninja recently introduced time-sensitive formatter such as %e (elapsed time in seconds) or %w (elapsed time, human readable), which are very useful. Unfortunately, our implementation of StatusTable doesn't refresh the status line every time the commands table is re-printed. When a long command hogs the build, the elapsed time remains unchanged on the status line while the command time duration is updated, which is a rather unfortunate user experience. To fix this, it is necessary for StatusTable to accept the timestamp from Status::BuildEdgeStarted(), which correspond to duration since an unknown epoch that Ninja recorded at the start of the build (but which happens well before StatusTable::BuildStarted() is called). This CL introduces the BuildTimeMillis and AsyncTimeMillis type aliases to distinguish between these time values, and those returned by AsyncLoop::NowMs(), which are relative to a completely different epoch. All values recorded in the map are in BuildTimeMillis, and a delta is computed lazily between the two timebases on the first call to CommandStarted() that follows BuildStarted(). Without this, the next CL would be unable to display correct timings. - Change StatusTable::CommandStarted() to accept a BuildTimeMillis value, which is recorded in the map. + Add AsyncLoop::ScopedTestClock::NowMs() for tests. Bug: 372310735 Change-Id: Ia0508fa21970c281bf0c48cac18a6bdfd7b45edb
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.
If you have a GoogleTest source directory, you can build the tests by passing its path with --gtest-source-dir=PATH option, or the GTEST_SOURCE_DIR environment variable, e.g.:
./configure.py --bootstrap --gtest-source-dir=/path/to/googletest ./ninja all # build ninja_test and other auxiliary binaries ./ninja_test` # run the unit-test suite.
Use the CMake build below if you want to use a preinstalled binary version of the library.
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
You must have asciidoc and xsltproc in your PATH, then do:
./configure.py ninja manual doc/manual.pdf
Which will generate doc/manual.html.
To generate the PDF version of the manual, you must have dblatext in your PATH then do:
./configure.py # only if you didn't do it previously. ninja doc/manual.pdf
Which will generate doc/manual.pdf.
If you have doxygen installed, you can build documentation extracted from C++ declarations and comments to help you navigate the code. Note that Ninja is a standalone executable, not a library, so there is no public API, all details exposed here are internal.
./configure.py # if needed ninja doxygen
Then open doc/doxygen/html/index.html in a browser to look at it.