Gracefully handle Ctrl-C when waiting for command completion. Change the logic when waiting for all processes to complete cleanly, for example after a failed command was detected, or when the user interrupted the build with a first Ctrl-C manually. In the case where the wait is too long, because some sub-commands are stuck, the user may be tempted to press Ctrl-C a second time. In this case, print a message telling how many commands Ninja is waiting, and warn about leaving zombie processes when pressing Ctrl-C a third time. This also prints a table of up to 8 commands being waited for to identify the problem. If the user insists, force the exit to let Ninja return immediately to the user. This behavior works consistently between normal and persistent build mode. Note that when Ctrl-C is pressed three times, the persistent server process will now stay live instead of aborting, removing the "Could not connect to server: ..." error that was happening previously. This requires changing the Subprocess::Start() and SubprocessSet::Add() signatures to support a new optional 'description' argument, which is made default-initialized to minimie changes to unit-test code. Bug: 452866538 Change-Id: Icf610d0d9f150904b7b0f412a7a4ce33ec50593e
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.
To build the ninja binary without building the unit tests, disable test building by setting BUILD_TESTING to OFF:
cmake -Bbuild-cmake -DBUILD_TESTING=OFF 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, omit the -DBUILD_TESTING=OFF option, and after building, run:
./build-cmake/ninja_test
You must have asciidoc and xsltproc in your PATH, then do:
./configure.py ninja manual doc/manual.html
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.