Introduces a `--status FMT` command-line flag that configures the
progress status using Ninja's regular `$var`/`${var}` syntax with
descriptive variable names ($finished, $total, $progress, $elapsed,
etc.) instead of the `%`-escapes used by `NINJA_STATUS`. When passed,
it takes precedence over `NINJA_STATUS`; the env-var path is left
unchanged for backwards compatibility.
Only the part of the graph that depends on the edges with a dyndep
binding may be affected by content loaded from the dyndep file.
Otherwise the dyndep file could change the build graph in a way that
causes already up-to-date build statements to become out-of-date.
Detect that the environment variable MAKEFLAGS specifies a
jobserver pool to use, and automatically use it to control
build parallelism when this is the case.
NOTE: On Posix, the pipe-based protocol is not supported and
will be detected. Ninja will print a warning on startup then
ignore the content of MAKEFLAGS (there is a regression test
for this).
This is disabled is `--dry-run` or an explicit `-j<COUNT>`
is passed on the command-line. Note that the `-l` option
used to limit dispatch based on the overall load factor
will still be in effect if used.
+ Use default member initialization for BuildConfig struct.
+ Add a new regression test suite that uses the
misc/jobserver_pool.py script that was introduced in
a previous commit, to verify that everything works
properly.
The 'multi-inputs' option will list all <target> + <inputs> for
the given targets.
Run:
ninja -t multi-inputs <target1> <target2> <target3>
Ninja will then output:
<target1> <input_x>
<target1> <input_y>
<target2> <input_x>
<target2> <input_z>
<target3> <input_y>
The introduction of the entry for `compdb-targets` in the `[horizontal]`
labeled list in doc/manual.asciidoc revealed some display issues in the
left column:
First, the web browser would insert a line break in the middle of the
label `compdb-targets`, so that it looked like this:
compdb-
targets
We fix this by applying the `white-space: nowrap` attribute to the left
column.
After this is fixed, we see practically no space between the end of the
longest label and the beginning of the text in the second column; we fix
this with the `padding-right` attribute.
Finally, we align all labels to the right side of the column so that
there is a consistent amount of horizontal space between the end of each
label and the beginning of the text in the second column.
This has been bugging me for *years*. :)
Count of finished edges isn't a great statistic, it isn't
really obvious if LLVM will take 8 minues to build, or 10 minutes.
But, it's actually pretty straight-forward to get some
more useful information. We already know how much time each edge
has taken, so we could just do the dumb thing, and assume that
every edge in the plan takes the same amount of time.
Or, we can do better. `.ninja_log` already contains
the historical data on how long each edge took to produce it's outs,
so we simply need to ensure that we populate edges with that info,
and then we can greatly improve our predictions.
The math is pretty simple i think.
This is largely a port of a similar change i did to LLVM LIT:
https://reviews.llvm.org/D99073
With this, i get something quite lovely:
```
llvm-project/build-Clang12$ NINJA_STATUS="[%f/%t %p %P][%w + %W] " /repositories/ninja/build-Clang-debug/ninja opt
[288/2527 11% 4%][00:27 + 08:52] Building CXX object lib/DebugInfo/CodeView/CMakeFiles/LLVMDebugInfoCodeView.dir/AppendingTypeTableBuilder.cpp.o
```
I hope people will find this useful, and it could be merged.
This sorts the output of `ninja -t inputs` to make it
deterministic and remove duplicates, and adds a regression
test in output_test.py
+ Ensure all inputs are listed, not only explicit ones.
+ Document the `inputs` tool in doc/manual.asciidoc.
The word "eventually" was quite strange here and should probably removed. I
suspect "potentially" was meant (which in French is "eventuellement", a standard
false friend). In any way, after a quick look at the source/ninja message, I
chose to even clarify this part of the doc, indicating that the `-d` option is
required here.
A common problem in the Android build is inserting rules that perform
some sort of error checking that doesn't produce any artifacts needed
by the build, for example static analysis tools. There are a few
patterns currently used, both of which have downsides.
The first is to have a rule that depends on all of the static analysis
results. This ensures they run, but requires running static analysis
over everything, and not just the active parts of the build graph.
The second is to insert the static analysis rule into the build graph
between the artifact producing rule and anything that depends on it,
often copying the artifact as the output of the static analysis rule.
This increases the critical path of the build, often reducing
parallelism. In the case of copying the artifact, it also wastes
disk space.
This patch adds "validation nodes" to edges in Ninja. A build
statement can specify validation nodes using "|@" in the edge
inputs. The validation nodes are not used as an input to the edge
(the edge can run before the validation node is ready), but are
added to the initial nodes of the build graph whenever the edge
is part of the build graph. The edge that outputs the validation
node can depend on the output of the edge that is being validated
if desired.
Test: ninja_test
Change-Id: Ife27086c50c1b257a26509373199664680b2b247
This commit fixes issue #478.
Observed:
Real edges depending on a phony edge will not be marked as dirty or
rebuilt if the phony's (real) inputs are updated.
Expected:
An edge should always be rebuilt if its inputs or transitive inputs are
newer than the output's mtime.
Change:
Node::mtime_ was overloaded, 0 represented "does not exist". This change
disambiguates it by adding Node::exists_. Then to fix the observed
behaviour, Node::UpdatePhonyMtime was added to update the mtime if the
node does not exist.
Add tests BuildTest.PhonyUseCase# GraphTest.PhonyDepsMtimes.
Unit tests will also test for always-dirty behaviour if a phony rule has
no inputs.
The ANSI code page identifier is more information than generator
programs actually need. The encoding of `build.ninja` is always
either UTF-8 or the system-wide ANSI code page. Reduce the output
to provide no more information than the generator programs need.
The Console code page can be obtained in other ways, so drop it.
Since commit 00459e2b (Use UTF-8 on Windows 10 Version 1903, fix#1195,
2021-02-17), `ninja` does not always expect `build.ninja` to be encoded
in the system's ANSI code page. The expected encoding now depends on
how `ninja` is built and the version of Windows on which it is running.
Add a `-t wincodepage` tool that generators can use to ask `ninja`
what encoding it expects.
Issue: #1195
