The value of the variable is parsed like command line arguments. You can for instance use less cores than available (-j), or limit the parallelism based on the system load (-l). For instance, on a build server used by multiple users, you may want to set NINJA_FLAGS=-l 1 on the system level, so that the server never gets overloaded by parallel ninja builds. Command line parameters override the flags set with NINJA_FLAGS.

WIP for issue #1195. Updated version using windows native API for converting between wide and utf8 for increased speed. Fixed buildissue for mingw and added needed defines to the cmake script.

Metrics for building chromium ` Ninja Master metric count avg (us) total (ms) .ninja parse 4849 1931.3 9364.8 canonicalize str 1889079 0.0 58.5 canonicalize path 1985429 0.0 42.8 lookup node 1932008 0.0 36.7 .ninja_log load 1 1504.0 1.5 .ninja_deps load 1 1314.0 1.3 node stat 7363 285.0 2098.4 depfile load 22 184.6 4.1 StartEdge 823 5840.9 4807.1 FinishCommand 822 3970.5 3263.8 CLParser::Parse 753 618.3 465.6

Ninja UTF8-version metric count avg (us) total (ms) .ninja parse 4849 2104.7 10205.6 canonicalize str 1889079 0.0 90.5 canonicalize path 1985429 0.0 60.8 lookup node 1933885 0.1 169.9 .ninja_log load 1 2000.0 2.0 .ninja_log recompact 1 14878.0 14.9 node stat 8748 260.8 2281.1 .ninja_deps load 1 3960.0 4.0 depfile load 22 209.7 4.6 StartEdge 823 5909.6 4863.6 FinishCommand 822 908.7 746.9 CLParser::Parse 753 615.2 463.2 `

This is a tool that detects some classes of random build failure causes around generated files (in Chrome, these are usually generated headers for C/C++). It takes several seconds to run, (more if the optional scan for files with no generator is used), and allows fixing a significant number of build system issues before they happen to randomly break someone's build.

The check relies on the correctness of depfile information, and on having all generator outputs listed. These things are usually easier to get right than proper deps. There's some overlap between this and gn check, but unlike gn check, this checks the actual ninja build graph and sees all issues.

This is a redo of https://github.com/ninja-build/ninja/pull/1031, it's been a while so I think it maybe better to start from scratch.

This is a better, faster approach than #1753 for providing robustness against inputs changing during the build. It fixes #1162 and #1940.

When recording the outputs' mtimes when the command finishes, use the remembered temporary file's mtime from when the edge started for recording in the build log. Subsequent runs will use that as the mtime for the output.

This provides robustness against inputs changing while the command itself is running. If an input is changed, the subsequent run will detect the output as dirty since its recorded mtime reflects when the build command began, not when the output was actually written to disk.

In order to allow future use of std::chrono to make the stats code portable it is desirable to compile with C++11. Doing so also allows use of std::unordered_map, and reduces the number of #ifdefs in the ninja source code.

Switching to C++11 requires modifying both CMakeLists.txt and configure.py, for MSVC and for other build systems. For MSVC the required change is adding /Zc:__cplusplus to tell the compiler to give a more accurate value for the __cplusplus macro. For other platforms the change is to add -std=c++11 or the CMake equivalent.

This change makes some progress towards resolving issue #2004.

I've been reviewing the source for ninja, and see a lot of areas where c++11 or newer features would be nice to have, but aren't currently used, like the "= default;" keyword for constructors and destructors, ranged based for loops, nullptr, lambdas, constexpr, so on.

What's the maximum c++ version that ninja's codebase abides by?

environment :Mac
Install ninja with the brew intsall ninja command then on terminal execute ninja occur ninja: error: loading 'build.ninja': No such file or directory 。 ➜ ~ ninja ninja: error: loading 'build.ninja': No such file or directory ➜ ~

Why is this problem still occurring when you have successfully installed ninja?

Currently we handle Makefile rules of the form:

out: in1 in2 in3

and the form:

out: in1 \
     in2 \
     in3

Teach the depfile parser to handle the additional form:

out: in1
out: in2
out: in3

This is also valid Makefile syntax and is the depfile format generated by the Intel Compiler for Windows.

Ninja lacks an option to force re-building of a particular target, like the make -B option.

I would be willing to implement this if someone could guide me through what needs to be done.

Before this change, symlinks were always followed when retrieving mtimes. This can cause ninja to think targets are stale when outputs are symlinks.

This patch introduces the following stat() logic for symlinks:

1. When Stat()ing inputs, use the newer of the symlink or what it points to.

• By looking at both, it maintains the pre-existing behaviour, where you could use a symlink as an input and ninja would know to rebuild when the thing it points to changes.
  1. When Stat()ing outputs, always use the timestamp of the symlink.
• If it's listed as an output, then it contains the only mtime ninja should care about.

Fixes Bug #1186

On Windows (XP or greater), Command lines are limited in length to 8,191 bytes.

Windows compiler toolsets (and gcc) get around this by allowing the @filepath syntax on the command line.

e.g. link.exe @Temp\MyLongLinkLinesInAFile.rsp

will run link.exe, which will then use the contents of the file Temp\MyLongLinkLinesInAFile.rsp as if they were on the command line.

This issue is to suggest that it is only ninja that could know the command line is being exceeded. A generator of .ninja files could know they are getting close, but couldn't know that 8.191 bytes exactly has been reached.

This issue is raised to ask if a patch to ninja that wrote >8191 character command lines into a file then called the build rule with the file (ninja to name the file) could be acceptable. If so, what exactly should the patch do? I propose:

ninja detects it's on Windows and total command line to run is >8,191 characters ninja creates a .rsp file in Temp with a unique name ninja writes command line argument contents into that file ninja invokes the original command line first argument but with the @filename syntax ninja cleans up the .rsp file

Do others have any thoughts on this?

This implements https://github.com/ninja-build/ninja/issues/370.

[Edit: Since this tracks the set of loaded files, I also enhanced it to also implement #2217 (#pragma once when loading files). The implementation here is better because it takes into account the fact that files can be loaded in two ways (include and subninja). It makes it an error to load the same file twice in two different ways. It would be trivial to change the implementation to make it an explicit error to load the same file twice, if this is preferred.]

[Edit 2: Modified implementation so always tries to build each loaded files before the 1st load. This allows an updated generator action to fix a loaded file with errors in it. As a bonus this means no modifications to the base parser, only to the manifest parser (and the main program to match).]

This is a natural extension of the current iterative way that ninja deals with the main input file. That is, it allows ninja to update any include or subninja file, similarly to how it updates the main input build.ninja file. Actually, it goes further - it can also create any loaded files if they doesn't exist yet (which obviously is not possible for the main input file).

For example, it allows placing a fixed small build.ninja file in the root of the working directory, check it in as part of the sources, and keep the sources directory read-only when building:

include build-dir/generated.ninja

# Normal build statement, e.g. w/ dependencies
build build-dir/generated.ninja: generate_ninja

rule generate_ninja
    command = create_build_dir_and_generate_ninja_in_it

Running ninja in a clean top-level directory will generate build-dir/generated.ninja, then include it and continue as usual. Currently one needs to run an arbitrary project-specific bootstrap command before running ninja for the first time.

Regardless of bootstrapping, It is also very convenient to be able to define dependencies for the loaded files, so that ninja will update them when needed. Specifically, if the generator program depends on some configuration file(s), or is directly modified, then running ninja will automatically detect this and update the files. Currently this is only true for the main input file, which makes it more difficult to split the generated build files to follow some modular project structure.

The new output format contains the same information and is almost exactly the same as before but it adheres to the makefile syntax which increases its operability. This change allows the generated output to be directly used in makefiles or other tools capable of dealing with makefile syntax.

For my work, I'm using ninja to build the project with vscode. Using MinGW Makefiles, the build succeeds. With Ninja, it fails with the following output:

[build] [127/2406 4% :: 19.355] Building CXX object vptlib/techsupport/CMakeFiles/vptlib_tech.dir/motif_wrap.cxx.o [build] [128/2406 4% :: 19.408] Building C object vptlib/techsupport/CMakeFiles/vptlib_tech.dir/aggregate_messages.c.o [build] [129/2406 4% :: 19.424] Building CXX object vptlib/util/CMakeFiles/vptlib_util.dir/otabp_check.cxx.o [build] FAILED: vptlib/util/CMakeFiles/vptlib_util.dir/otabp_check.cxx.o [build] /usr/bin/ccache /opt/rh/devtoolset-7/root/usr/bin/g++ -I../vptlib/diag -I../vptlib/frm -I../vptlib/helper -I../vptlib/main -I../vptlib/xo -I../vptlib/sbs -I../vptlib/json -I../vptlib/sb -I../vptlib/sem -I../vptlib/lib -I../vptlib/util -I../vptlib/postbus -I../vptlib/prot -I../vptlib/ufw_lib -I../vptlib/log/include -I../vptprllib/alg -I../vptprllib/vptprl_basis -I../vptprllib/vptprl_alg -I../vptprllib/vptprl_alg_c -I../vptprllib/database -I../vptprllib/unittest -I../prl/vpt24a_alg -I../prl/vpt24a_tk_i5 -I../prl/vpt24x_alg -I../prl/vpt25g_alg -I../prl/vpt25d_alg -I../vptlib/util/../helper -isystem /opt/openvms_tools/include -isystem /opt/tibco/ems/8.4/include/tibems -isystem /usr/include/oracle/12.2/client64 -isystem /opt/motif-itr/include -isystem ../vptlib/techsupport_include -isystem /usr/include/X11 -m64 -g -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -DLINUX -D_REENTRANT -DSPINLOCK -DD_DLLEXP= -DD_DLLIMP= -DLIBR8_AVAILABLE -Dlinux -std=c++17 -g --coverage -O0 -fno-omit-frame-pointer -fprofile-dir="/var/prl/profile" -fpermissive -pipe -fuse-ld=gold -Wall -Wextra -Werror -Wnon-virtual-dtor -pedantic-errors -Wno-unused-parameter -Wno-deprecated -fPIC -fPIC -fdiagnostics-color=always -MD -MT vptlib/util/CMakeFiles/vptlib_util.dir/otabp_check.cxx.o -MF vptlib/util/CMakeFiles/vptlib_util.dir/otabp_check.cxx.o.d -o vptlib/util/CMakeFiles/vptlib_util.dir/otabp_check.cxx.o -c ../vptlib/util/otabp_check.cxx [build] [129/2406 4% :: 19.583] Building CXX object vptlib/sbs/CMakeFiles/vptlib_bewaak.dir/bewaak_logger.cxx.o [build] [129/2406 4% :: 19.597] Building CXX object vptlib/sbs/CMakeFiles/vptlib_bewaak.dir/bewaak_data_updater.cxx.o

If I build again, the error is elsewhere:

[build] [76/2278 2% :: 13.124] Building CXX object vptlib/frm/CMakeFiles/vptlib_frmtest.dir/smt_frm_edit_test.cxx.o [build] [77/2278 2% :: 13.126] Building C object vptlib/xo/CMakeFiles/vptlib_xo.dir/bbox.c.o [build] FAILED: vptlib/xo/CMakeFiles/vptlib_xo.dir/bbox.c.o [build] /usr/bin/ccache /opt/rh/devtoolset-7/root/usr/bin/gcc -I../vptlib/diag -I../vptlib/frm -I../vptlib/helper -I../vptlib/main -I../vptlib/xo -I../vptlib/sbs -I../vptlib/json -I../vptlib/sb -I../vptlib/sem -I../vptlib/lib -I../vptlib/util -I../vptlib/postbus -I../vptlib/prot -I../vptlib/ufw_lib -I../vptlib/log/include -I../vptprllib/alg -I../vptprllib/vptprl_basis -I../vptprllib/vptprl_alg -I../vptprllib/vptprl_alg_c -I../vptprllib/database -I../vptprllib/unittest -I../prl/vpt24a_alg -I../prl/vpt24a_tk_i5 -I../prl/vpt24x_alg -I../prl/vpt25g_alg -I../prl/vpt25d_alg -isystem /opt/openvms_tools/include -isystem /opt/tibco/ems/8.4/include/tibems -isystem /usr/include/oracle/12.2/client64 -isystem /opt/motif-itr/include -isystem ../vptlib/techsupport_include -m64 -g -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -DLINUX -D_REENTRANT -DSPINLOCK -DD_DLLEXP= -DD_DLLIMP= -DLIBR8_AVAILABLE -D_GNU_SOURCE -std=c11 -g --coverage -O0 -fno-omit-frame-pointer -pipe -fuse-ld=gold -fprofile-dir="/var/prl/profile" -Wall -Wextra -Werror -Wno-unused-parameter -fPIC -fdiagnostics-color=always -MD -MT vptlib/xo/CMakeFiles/vptlib_xo.dir/bbox.c.o -MF vptlib/xo/CMakeFiles/vptlib_xo.dir/bbox.c.o.d -o vptlib/xo/CMakeFiles/vptlib_xo.dir/bbox.c.o -c ../vptlib/xo/bbox.c [build] [77/2278 2% :: 13.253] Building C object vptlib/xo/CMakeFiles/vptlib_xotest.dir/xo_geometry_test_c.c.o [build] [77/2278 2% :: 13.373] Building C object vptlib/xo/CMakeFiles/vptlib_xotest.dir/xo_test_c.c.o [build] [77/2278 2% :: 13.387] Building C object vptlib/xo/CMakeFiles/vptlib_xo.dir/arc.c.o

I am running Ninja 1.10.2 on a RH Red Hat Enterprise Linux Server 7.9 (Maipo) (VM), using Windows.

Is ninja expected to work on case-insensitive file systems?

I've already learnt that inputs and outputs are matched case-sensitive, which is causing quite a headache in our ninja file generation process, but it's something we can handle and just need to get consistent. Now, we have come across a problem that we're struggling with. Let's do this by example:

rule copy
   command = cmd /c copy $in $out
   
build out: copy in

We run ninja on this, which simply copies file "in" to "out" and stores the creation of "out" in the .ninja_log file. Now, we do a small change to the ninja file and change "out" to upper-case "OUT":

rule copy
   command = cmd /c copy $in $out
   
build OUT: copy in

When executing "ninja -t cleandead" on this changed file, it will clean 1 file: the "out" file. Though, we still have a build statement creating "OUT".

As we are on a case-insensitive file system this isn't what we would like to see. In our specific use case the file that will be cleaned is a ninja file rendering the whole build to be broken (we use some selftest build statements to find out whether we need to update generated ninja files, generate ninja files if we need to, then invoke cleandead to get rid of old outputs from previous builds, and only after that invoke ninja to take care of actually building the software).

What's the recommended solution for ninja on case-insensitive file systems? Should we always generate ninja files with lower-case files as inputs and outputs to avoid that something changes, if someone changes the case of a file or directory? Preferably, Ninja would do this on its own ;-)

GNU Make uses /proc/loadavg on Linux to decide whether to start another task: https://lwn.net/Articles/913253/ / https://git.savannah.gnu.org/cgit/make.git/commit/src/job.c?id=d8728efc80b720c630e6b12dbd34a3d44e060690. I would like Ninja to do the same.

Since /proc/loadavg provides "number of processes currently runnable (running or on ready queue)" (https://www.kernel.org/doc/html/latest/filesystems/proc.html), Ninja would be able to take better decisions than by looking only at the info provided by getloadavg().