set -x NINJA_STATUS "STEP: %f/%t
[%p / %P]
[%w + %W]
"
https://neugierig.org/software/chromium/notes/2011/02/ninja....
Hence, it's used in a lot of Google projects.
Some blog posts from the creator of ninja:
https://neugierig.org/software/blog/2018/07/options.html
https://neugierig.org/software/blog/2011/04/complexity.html
Also there was a post about why just generating ninja using python can be a good option. I do this in my project and it has been very productive so far. I couldn’t find this post now but it was saying to use ninja_syntax.py from ninja codebase and just doing something minimal for a project
You switched some branches back and forward? Enjoy your 20 minutes rebuild.
[0] https://pypi.org/project/ninja/
[1] https://github.com/scikit-build/ninja-python-distributions/i...
1) pick a source file and make a copy of it for for later 2) edit selected source file and rebuild 3) move the copy to it's original location 4) try to rebuild, nothing happens
https://neugierig.org/software/blog/2018/07/options.html
(hello FreeCAD ;)
How do you know though when the choice of cmake-generator is entirely up to the user? E.g. you can't look at a cmake file and know what generator the user will select to build the project.
FWIW I usually prefer the Ninja generator over the Makefile generator since ninja better 'auto-parallelises' - e.g. with the Makefile generator the two 'simple' options are either to run the build single-threaded or completely grind the machine to a halt because the default setting for 'parallel build' seems to heavily overcommit hardware resources. Ninja just generally does the right thing (run parallel build, but not enough parallelism to make the computer unusable).
There is (at least) one open issue about this - the solution/alternatives are not trivial:
Bazel and Shake avoid this class of bug with content hashes, so a rename, restore, or tar extract does not leave the build graph in a stale state. Speed matters, but not enough to bet your repo on timestamp luck.
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.
Copy and edit do, but move (aka rename) generally does not, and that is the part that is problematic.
I don't think the described sequence of operations is all that unusual. Not the most common case for sure, but hardly unlikely in the grand scheme of things.
Hash-aware build systems like bazel, if that's what you're imputing, are a nightmare to work with and come with their own set of problems which make it much less appealing to work with than (some) limitations found in cmake+ninja
Incorrect, I only assume move/rename of backup to original location doesn't change it's mtime (which it doesn't with default flags or from IDE or file manager). And I don't think this is a weird or obscure workflow, I do it all the time - have two versions of a file or make a backup before some experimental changes, and restore it later.
1. A library depends on a system package. To test against the different versions of the system package, the library is compiled within a container.
2. To minimize the incremental rebuild time, the `build` directory is mounted into the build container. Even when using a different version of the system package, this allows re-use of system-independent portions of the build.
3. When switching to a build container with a different version of the system package, the mtime of the system package is that of its compilation, not that of the build container's initialization. Therefore, the library is erroneously considered up-to-date.
Because the mtime is the only field checked to see if the library is up to date, I need to choose between having larger disk footprint (separate `build` directory for each build container), slower builds (touch the system package on entering the container, forcing a rebuild), or less safe incremental builds (shared `build` directory, manually touch files when necessary).