| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
When a path loaded from a depfile does not have a node, we create a new
node with a phony edge producing it. If we later load a dyndep file
that specifies the same node as an output of a known edge, we previously
failed with a "multiple rules generate ..." error. Instead, since the
conflicting edge was internally generated, replace the node's input edge
with the now-known real edge that produces it.
|
| |
|
|
|
|
|
| |
These expose some behavior related to implicit deps unknown to ninja and
timestamps with generating them as part of a rule.
See discussions in #1932 and #1933.
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 67fbbeeec91ec171da7d4e297b8f9b319f3424c8.
There were a few missing test cases exposed by CMake's test suite that
need slight adjustments. Better to revert the original attempt, add the
test cases, and then re-land the change with the fixes.
Fixes #1932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an edge's output files' mtimes are compared to the most recent
input's mtime, edges might be calculated as clean even if they are
actually dirty. While an edge's command is running its rule to produce
its outputs and an input to the edge is updated before the outputs are
written to disk, then subsequent runs will think that the outputs are
newer than the inputs, even though the inputs have actually been updated
and may be different than what were used to produce those outputs.
Ninja will now restat all inputs just prior to running an edge's command
and remember the most recent input mtime. When the command completes,
it will stat any discovered dependencies from dep files (if necessary),
recalculate the most recent input mtime, and log it to the build log
file. On subsequent runs, ninja will use this value to compare to the
edge's most recent input's mtime to determine whether the outputs are
dirty.
This extends the methodology used by restat rules to work in all cases.
Restat rules are still unique in that they will clean the edge's output
nodes recursively if the edge's command did not change the output, but
in all cases, the mtime recorded in the log file is now the most recent
input mtime. See the new tests for more clarification.
|
| |
|
|
|
|
| |
Make BuildStatus an abstract interface, and move the current
implementation to StatusPrinter, to make way for a serialized
Status output.
|
| |
|
|
|
|
|
| |
Store the number of running edges instead of trying to compute it
from the started and finshed edge counts, which may be different
for starting and ending status messages. Allows removing the status
parameter to PrintStatus and the EdgeStatus enum.
|
| |
|
|
|
|
|
|
| |
The times that end up in the build log currently originate in the
status printer, and are propagated back out to the Builder. Move
the edge times into the Builder instead, and move the overall start
time into NinjaMain so it doesn't get reset during manifest
rebuilds.
|
| |
|
|
|
|
| |
Found with google-explicit-constructor
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
| |
|
|
| |
header files
|
| |
|
|
|
| |
Found with readability-container-size-empty
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
| | |
|
| |
|
|
|
|
|
| |
* build: constify EdgeWanted()
* build: constify a bit of CommandRunner
* graph: constify functions of struct Edge
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Replace our single active edge pointer with a vector and add a
parameter that tests can set to limit the number of concurrent
edges. Set the default to 1 to preserve the current behavior.
Specific tests will be able to override it later to simulate
concurrent builds.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit v1.8.0^2~3^2~1 (Teach RecomputeDirty to detect cycles in
the build graph, 2015-11-13) we correctly reject self-referencing phony
build statements like
build a: phony a
as cycles. Unfortunately this breaks support for CMake 2.8.12.x and
3.0.x because those versions incorrectly produce edges of this form
(that we used to tolerate). In order to preserve compatibility with
those CMake versions we need to restore tolerance of these edges.
Add a special case to the manifest parser to filter out self-referencing
inputs of phony edges of the form produced by those CMake versions.
Warn by default, but add a `-w phonycycle={err,warn}` option to make it
an error.
Fixes: #1322
|
| |
|
|
|
| |
We now detect and reject cycles in DependencyScan::RecomputeDirty before
Plan::AddTarget is called so we can assume DAG input to the Plan.
|
| |
|
|
|
| |
Remove a dependency cycle from the test case, as cycles are covered by
other tests. Ensure this case covers stat failure on a valid graph.
|
| |
|
|
|
|
|
|
| |
PR #1281 added a deference of most_recent_input without checking
for NULL, which can occur if a build rule has no inputs.
Check it for null before dereferencing, and add a test.
Fixes #1290.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With this build file:
pool failpool
depth = 1
rule fail
command = fail
pool = failpool
build out1: fail
build out2: fail
build out3: fail
build final: phony out1 out2 out3
Running `ninja -k 0` should run out1..3 sequentially before failing, but
until recently we would fail after just running out1. Add a test
covering this case.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some build rules produce outputs that are not mentioned on the command
line but that should be part of the build graph. Such outputs should
not be named in the `$out` variable. Extend the build statement syntax
to support specification of implicit outputs using the syntax
`| out1 out2` after the explicit outputs and before the `:`.
For example, compilation of a Fortran source file `foo.f90` that defines
`MODULE FOO` may now be specified as:
rule fc
command = f95 -c $in -o $out
build foo.o | foo.mod: fc foo.f90
The `foo.mod` file is an implicit output generated by the compiler based
on the content of the source file and not mentioned on the command line.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #934. Plan::AddSubTarget() tracks in want_ if each edge has been
visited and visits every edge only once. But Plan::CheckDependencyCycle()
worked on nodes however, so if a cycle was entered through an edge with
multiple outputs, ninja would fail to detect that cycle.
Move cycle detection to look for duplicate edges instead of nodes to fix
this. The extra jump makes CheckDependencyCycle() a bit slower: for a
synthetic build file with 10000 serial build steps, `ninja -n` now takes
0.32s instead of 0.26s before on my laptop. In practice, projects have
a dependency change length on the order of 50, so there shouldn't be a
noticeable slowdown in practice. (If this does end up being a problem:
CheckDependencyCycle() currently does O(n) work and is called O(m) times
from AddSubTarget(), so I think cycle checking is O(n^2) in the build
depth. So instead of worrying about constant overhead, we could use
a set<> instead of a stack<>. But it doesn't seem to be a problem in
practice.)
|
| |
|
|
|
|
|
|
|
| |
Also check for Stat() failure in a few more places.
This way, ninja doesn't print two "ninja: error: " lines if stat() fails
during a build. It also makes it easier to keep the stat tests quiet.
Every caller of Stat() needs to explicitly log the error string if
that's desired.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #830, fixes #904.
In practice, this either happens with 64-bit inodes and a 32-bit
userspace when building without -D_FILE_OFFSET_BITS=64 in CFLAGS, or
when a filename is longer than the system file length limit.
Since DiskInterface::Stat() returns -1 on error, and Node used -1 on
"stat state unknown", not aborting the build lead to ninja stat()ing the
same file over and over again, until it finally ran out of stack. That's
now fixed.
* Change RecomputeOutputsDirty() to return success instead of dirty
state (like RecomputeDirty()) and return the dirty state in a bool
outparam
* Node::Stat()s old return value wasn't used anywhere, change the
function to return success instead and add an |err| outparam
* Node::StatIfNecessary()'s old return value was used only in one place.
Change that place to explicitly check status_known() and make
StatIfNecessary() return success and add an |err| outparam
* Plan::CleanNode() can now fail, make it return bool and add an |err|
outparam
|
| |
|
|
| |
Fixes #417.
|
| |
|
|
| |
This is a prerequisite for fixing #417.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ninja currently uses googletest for testing. That makes building
ninja_test somewhat annoying since it requires that one passes
--with-gtest PATH to configure. It turns out just implementing the bits
of googletest that ninja uses needs about the same amount of code than
making the --with-gtest flag in configure.py work and making googletest
print test results in a way we want (!)
In addition to making configuration simpler, this also makes compiling
tests much faster: On my system, touching src/build_test.cc (the slowest
file to build in ninja) and rebuilding ninja_tests is twice as fast than
without this patch. Building all is noticeably faster too: 5.6s with
this patch, 9.1s without this patch (38% faster).
The most noticeable things missing: EXPECT_* and ASSERT_* don't support
streaming notes to them with operator<<, and for failing tests the lhs
and rhs are not printed. That's so that this header does not have to
include sstream, which slows down building ninja_test almost 20%.
If this turns out to be annoying, we can maybe add it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #730. This has always been broken, but due to #690 more paths are now
escaped (e.g. paths containing + characters, like file.c++). Also see
discussion in #689.
The approach is to give EdgeEnv an enum deciding on whether or not to escape
file names, and provide functions that evaluate depfile and rspfile with that
set that to kNoEscape. (depfile=$out.d doesn't make sense on edges with
multiple outputs.)
This should be relatively safe, as $in and $out can't be used on edges, only
on rules (#687).
|
| | |
|
| |
|
|
|
|
|
| |
This is a pre-defined pool with a depth of 1. It has the special property
that any task in the pool has direct access to the console. This can be
useful for interactive tasks or long-running tasks which produce status
updates on the console (such as test suites).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
