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.
Since commit 8e6c741a4b ("explain" debug prints just before each command
is run, 2022-01-06, v1.13.0~1^2~56^2~2) the "loading dyndep file '...'"
explanation has not been printed. Instead the explanation has been
recorded for the dyndep file's node *after* it has been brought
up-to-date, and therefore never printed.
This explanation is generated just before its operation runs, so we can
print it immediately instead of buffering it.
Fixes: #2758
This was regressed by commit 8e6c741a4b ("explain" debug prints just
before each command is run, 2022-01-06, v1.13.0~1^2~56^2~2). Add a
test demonstrating the problems, called out by FIXME comments.
Issue: #2758, #2759
This fixes ##2681, a regression that was introduced during PR #2540
where Ninja would return a status code of 0 when interrupted.
The problem comes from RealCommandRunner::WaitForCommand() not
updating the result->status field in case of interrupt being
detected in Subprocess::DoWork().
This fixes the issue and adds a regression test for it.
+ Fix the CommandRunner::Result constructor to ensure that
the `status` field is always initialized, even though it
should now always be replaced at the end of a command.
Targets which use multiple input files only have their first input
file show up in the compilation database. This can cause issues with
tools that build a list of files to inspect from the compilation
database. For example, when using the Swift programming language
together with the SourceKit-LSP language server, only one source file
from each Swift module gets processed correctly by the language server
using the current compilation database output from Ninja, because Swift
modules are compiled with one compiler invocation and therefore one
Ninja target for the whole module.
This changes the compilation database formatter to emit one entry
for each input file of a target instead of just the first input
file, which makes tools able to pick up all the input files used in
the build.
Fixes#1590.
See also https://github.com/mesonbuild/meson/pull/14264.
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.
This implements a GNU jobserver token pool that will be used
for testing the upcoming jobserver Ninja client implementation.
Note that the implementation is basic and doesn't try to deal
with broken protocol clients (which release more tokens than
they acquired). Supporting them would require something vastly
more complex that would monitor the state of the pipe/fifo
at all times.
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>
PR #2487 introduced a regression, where a completed command without
an output would force a newline, preventing the next status update
to appear on the same line in smart terminals.
This fixes the issue by adding the missing `!outputs.empty()`
condition + adding a proper regression test to catch future
breaks.
Fixed: #2499
For most actions, the depfile will be in the same directory as one
of its outputs, and their parent directory will be created by Ninja
before running the command. However, this is not always the case.
In particular, the GN build tool is changing its Ninja build plan
generation logic, switching from using stamp files to phony targets,
after issue #478 was fixed in Ninja. For additionnal context
see https://gn-review.googlesource.com/c/gn/+/11380.
The newly generated build plans trigger this condition more frequently,
which results in flaky build failures for large GN-based projects such
as Fuchsia.
This patch ensures the depfile's parent directory is always created
before the command is launched to get rid of the issue entirely.
Add new options to the `inputs` tool in order to change
the format of its output:
- `--no-shell-escape` to avoid shell-escaping the results.
- `--dependency-order` to return results in dependency order,
instead of sorting them alphabetically.
- `--print0` to use \0 as the list separator in the list,
useful to process the target paths with `xargs -0` and
similar tools.
This uses the InputsCollector class introduced in the
previous patch to implement the tool properly. Results
are still shell-escaped and sorted alphabetically.
Fixed#2482
Before #2067, ninja would have printed this instead for the second
`ninja` invocation:
ninja explain: output .FORCE of phony edge with no inputs doesn't exist
ninja explain: .FORCE is dirty
ninja explain: input is dirty
ninja explain: mid is dirty
[1/3] [ -e input ] || touch input
Do not use os.chdir() to change the current directory inside
the run() function, as doing this prevents the temporary directory
from being removed.
Moreover, this breaks pytest invocations when adding new regression
test scripts in this directory (as done in other forks).
+ Use dict.pop() to undefine environment variables in `default_env`
dictionary.
This fixes#1966 by removing the variable name from the
lookups stack once the recursive lookup call has been performed.
Without this, any previously expanded variable could no longer
be referenced in the command, as Ninja would (incorrectly)
complain about a cyclical dependency.
We default `ninja-indent-offset` to `2` because Meson and CMake use `1`
and `2` values accordingly, but `1` seems like too little, so use `2`.
The correctness was tested in particular on two `build.ninja` files,
one generated by Meson (1790 lines), and another by CMake (7777
lines). After setting `ninja-indent-offset` to the expected by the
file value and re-indenting whole file the buffer was left unchanged,
i.e. the calculated offset matched the ones already used.
The code previously did not take into account that between the name
and assignment may be any number of space including no space at all.
It was also incorrectly highlighting in a code like
foo = bar = buzz
the `bar` as a variable, even though the `bar = buzz` is just a text
that gets assigned to `foo`, i.e. `bar` is not a variable. Fix that.
- add `ninja` prefix to functions
- improve completion of `-d` and `-t`
- stop completion if `-h`, `--help`, or `--version` is supplied
- add missing `--verbose` options
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.
See comment in #1899. Also adds two tests to output_test.py which check
this behaviour by relying on Python's suprocess.check_output not piping
stderr.
