| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
manifest_parser: remove multi-output depslog restriction
|
| | |
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
|
| |
| |
| |
| | |
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
|
|/
|
|
|
|
| |
Modifying a key in C++ associative containers is UB.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
|
|
|
|
|
|
|
| |
* build: constify EdgeWanted()
* build: constify a bit of CommandRunner
* graph: constify functions of struct Edge
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
|
|\
| |
| | |
Emit "FAILED: " in red if terminal supports ANSI color output
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
After finishing an edge that produces a dyndep file, load the file and
update the build graph structure. Recompute the dirty state of all its
dependents and of newly reachable portions of the graph. Add edges to
the build plan that are discovered to be wanted. Finally, schedule
edges that are wanted and now ready to build.
|
| |
| |
| |
| |
| |
| |
| | |
In order to later support dynamic updates to the build plan while
building, the Plan will need access to its Builder. Since this access
will be needed only for specific features we can avoid updating all Plan
constructions in the test suite by making this access optional.
|
| |
| |
| |
| |
| | |
Move the logic to a new Plan::EdgeMaybeReady method so it can be re-used
elsewhere.
|
| |
| |
| |
| |
| | |
Move the logic to mark edges as wanted over to a Plan::EdgeWanted method
so it can be re-used elsewhere later.
|
| |
| |
| |
| |
| |
| |
| | |
Add an 'err' string argument and return a boolean for success. Update
call sites to pass an 'err' string argument and check the return value.
This will be useful later for adding logic to these methods that may
fail.
|
|/
|
|
|
| |
This method should be called only with edges that have not
already been started.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to introduction of depfile parser handling of multiple rules,
ninja silently accepted a depfile of the form:
out: in1 in2 in3
other: otherIn1 otherIn2 otherIn3
and incorrectly treated `other` and `otherIn*` as additional inputs to
`out`. Now we prefer to reject this just as we already do for a depfile
specifying multiple outputs on one line. However, this can break
existing cases where such a depfile was silently tolerated.
Add a `-w depfilemulti={err,warn}` option to control this behavior,
and make it just a warning by default.
|
|
|
|
|
| |
Don't strip colors when CLICOLOR_FORCE is set to a non-zero value. This
environment variable is also used by CMake's Make back-end.
|
|
|
|
|
|
| |
This reverts commit 52c1d0c8f8545231581c4d51cb0a85f50564c415.
Fixes #1418.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Developers tend to blame the last printed line when a build takes too
long. Unfortunately, when building concurrently, the last printed line
may have actually finished a long time ago. Under the current system,
ninja does not update the status line to reflect what jobs are still
running. This change makes ninja always print the oldest still running job
instead. In other words, the likely build bottlenecks.
Patch from David Zarzycki, originally uploaded at #1320.
|
|\
| |
| | |
Track in Plan whether wanted edges have been scheduled
|
| |
| |
| |
| |
| |
| |
| |
| | |
Refactor the `want_` map to track for wanted edges whether they have
been scheduled or not. This gives `ScheduleWork` a direct place to keep
this information, making the logic more robust and easier to follow. It
also future-proofs `ScheduleWork` to avoid repeat scheduling if it is
called after an edge has been removed from `ready_` by `FindWork`.
|
|/
|
|
|
|
| |
Ninja is supposed to be able to build as C++98 so it can run on old
systems, but it should also be possible to optionally build it with
newer dialects.
|
|
|
|
|
| |
We now detect and reject cycles in DependencyScan::RecomputeDirty before
Plan::AddTarget is called so we can assume DAG input to the Plan.
|
|
|
|
|
|
| |
All call sites have a node on which they call `in_edge()` to call
RecomputeDirty. Simplify call sites by taking the node directly and
calling `in_edge()` internally.
|
|\
| |
| | |
Write subprocess output to stdout in binary mode
|
| |
| |
| |
| |
| |
| |
| |
| | |
Set stdout to binary mode while writing subprocess output, so that the
CR in a CR LF sequence is not replaced with CR LF itself, which would
result in CR CR LF.
Based on patch posted by nico in issue #773 comment.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://groups.google.com/forum/#!msg/ninja-build/YQuGNrECI-4/ti-lAs9SPv8J
discusses a case where an rule updates its output file and then
fails. The next run of ninja considers the ouptut file clean
and doesn't rebuild it. Always stat output files after they are
built, and write the mtime into .ninja_log. Consider output files
dirty if the recorded mtime is older than the most recent input
file.
|
| |
| |
| |
| |
| |
| |
| |
| | |
https://groups.google.com/forum/#!msg/ninja-build/YQuGNrECI-4/ti-lAs9SPv8J
discusses a case where an rule updates its output file and then
fails. The next run of ninja considers the ouptut file clean
and doesn't rebuild it. Add a test for this case, which currently
fails.
|
|\ \
| | |
| | | |
Allow more path components
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- 60 instead of 30 path components
- 64 instead of 32 backslashes in a path (windows only)
Issue: 1161
|
|/ / |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #999 made dumb terminals only output when edges finish. PrintStatus
is called after finished_edges_ is incremented, which means the
calculation for running edges will always return 1 less than the real
number of running processes. This happens on smart terminals too, but
ninja will immediately print the status for the next edge with
starting_edges_ incremented, so the incorrect value is never visible.
Pass a boolean specifying whether the status is being printed on an edge
finishing, and if so count the edge that just finished as being running.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #999 made dumb terminals only output when edges
finish. BuildStatus::overall_rate_ stopwatch is only initialized to the
current time when PrintStatus is called with finished_edges_ == 0, but
on a dumb terminal it will be called for the first time when
finished_edge_ = 1, which results in very long elapsed times:
NINJA_STATUS="[%r processes, %f/%t @ %o/s : %es ] "
[0 processes, 2/2 @ 0.0/s : 1461869902.367s ]
Reset the stopwatches in BuildEdgeFinished before finshed_edges_ is
incremented instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #999 changed the status line to be printed when edges finish on dumb
teerminals, but the default status message includes the number of
started edges, resulting in sequential status lines with identical
edge counts.
Change the default status to show the number of finished edges, which
will keep the count incrementing on every line. This will slightly
change the output on smart terminals. Previously a build that was just
starting would show a count equal to the number of concurrent jobs, and
a build waiting for the final jobs to finish would show a count equal to
the total number of edges. Now a starting build will show 0, and build
waiting for the final jobs will show a count less than the total number
of edges by the number of remaining jobs.
Fixes: #1142
|
|
|
|
|
|
|
| |
Use an enumeration instead of a boolean to clarify the purpose of
arguments at call sites.
Suggested-by: Nico Weber <nicolasweber@gmx.de>
|
|\
| |
| | |
Release the pool slot held by an edge whether it succeeds or fails
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an edge finishes building, it should be release from its pool.
Make sure that this also is the case when an edge fails to build.
The bug can be shown with a pool has size N, then `ninja -k N+1` will
still stop after N failing commands for that pool, even if there are
many more jobs to be done for that pool:
pool mypool
depth = 1
rule bad_rule
command = false
pool = mypool
build a : bad_rule
build b : bad_rule
Current behaviour:
$ ninja -k 0
[1/2] false
FAILED: false
ninja: build stopped: cannot make progress due to previous errors.
Expected behaviour:
$ ninja -k 0
[1/2] false
FAILED: false
[2/2] false
FAILED: false
ninja: build stopped: cannot make progress due to previous errors.
Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
|
|\ \
| |/
|/| |
Avoid double-scheduling build edges in another case
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The change in commit v1.2.0~3^2~3^2~3 (Fix duplicate edge Pool crash in
the minimally invasive way, 2013-03-18) avoids double-scheduling in a
case involving duplicate out edges. However, double-scheduling may also
occur on a consistent graph when an edge and one of its dependencies
share an order-only input:
$ cat build.ninja
...
build c: touch
build b: touch || c
build a: touch | b || c
$ ninja a
$ rm a c
$ ninja a
In this case 'c' will build first. When NodeFinished('c') loops over
the out edges it will find AllInputsReady is true for 'b' and call
EdgeFinished('b') since it is not wanted (up to date). This will
call NodeFinished('b') which will loop over its out edges, find
AllInputsReady is true for 'a', and call ScheduleEdge('a'). When
we eventually return to the loop in NodeFinished('c') it will move
on to its second output and find that AllInputsReady is true for
'a' and call ScheduleEdge('a') again.
Teach ScheduleEdge to tolerate duplicate calls for an edge that has
already been scheduled. Avoid calling EdgeScheduled more than once
for the same edge.
|
|/
|
|
|
|
|
|
|
| |
This makes it possible to run most of the clparser tests on non-Windows,
and is potentially useful for cross-compiling on non-Windows hosts.
Also, the manual didn't document this as Windows-only previously.
If you use this on non-Windows, please let me know, else I might undo
this change again in the future.
|
|\
| |
| | |
Print output file on failure
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Modify the FAILED: output to provide the output files that failed to
build, followed by the failed command on the next line. This makes the
failure much easier to read, as you can immediately see much shorter
name of the file that failed instead of trying to parse a very long
command line. It also makes manually re-running the failed command much
easier because you can copy the whole line without ending up with the
FAILED: prefix.
|
| |
| |
| |
| |
| |
| | |
Return a status so callers can distinguish a missing file from an empty
file. This allows our VirtualFileSystem test infrastructure to report
as missing any file for which it has no entry.
|
| |
| |
| |
| |
| | |
This is useful when you are developing a tool which generates
GCC-style depfiles.
|
|\ \
| | |
| | | |
Print status when edge finishes on dumb terminals
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On smart terminals ninja prints the status line both before
and after running a command, reusing the same line if possible.
On a dumb terminal that doesn't support reusing the line, it
only prints the status before starting the command, but prints
the output of the command when the command finishes, by which
point other commands may have started and printed their status
line. This makes it impossible to determine what command
produced a line of output.
Modify BuildEdgeStarted to only print the status line if the
command is going to lock the console, or if ninja is running
on a smart terminal. Modify BuildEdgeFinished to always
print the status line unless the command locked the console,
in which case the status was already printed and no other
command can have printed any lines.
The end result will be dumb terminal output that much more
closely matches smart terminal output. One disadvantage is
that dumb terminals won't show anything when starting a
command, making it harder to tell what commands are currently
running, but I expect most interactive uses of ninja will use
a smart terminal.
|