| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #867, both the crashes and "[stuck]" issues.
The problem was that a duplicate edge would modify the in_edge of the
outputs of the new build rule, but the edge corresponding to the old
build rule would still think that the in_edge points to itself.
`old_edge->outputs_[0]->in_edge()` would not return `old_edge`, which
confused the scan logic.
As fix, let `State::AddOut()` reject changing in_edge if it's already
set. This changes behavior in a minor way: Previously, if there were
multiple edges for a single output, the last edge would be kept. Now,
the first edge is kept. This only had mostly-well-defined semantics if
all duplicate edges are the same (which is the only case I've seen in
practice), and for that case the behavior doesn't change.
For testing, add a VerifyGraph() function and call that every time any
test graph is parsed. That's a bit more code than just copying the test
cases from the bug into build_test.cc, but it also yields better test
coverage overall.
|
|
|
|
|
|
|
|
| |
Ninja didn't support scoping rules through subninja and assumed
a unique rule name in the whole namespace. With this change, this
behavior is changed to allow scoping rules. Two rules can have the
same name if they belong to two different scopes. However, two
rules can NOT have the same name in the same scope.
|
|
|
|
|
|
| |
The assert fires on cyclic manifests (found by afl-fuzz). Since there
was explicit error handing for this case already, just remove the
assert.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
Ideally we'd detect this at build time and only warn if your build
was affected, but that's hard to do. (Really we should just abort
when this scenario is detected rather than continuing, but now
users are relying on it.)
Hopefully improves issue #543.
|
|
|
|
|
| |
DepsLog is a compact serialization of dependency information.
It can be used to replace depfiles for faster loading.
|
| |
|
| |
|
|
|
|
|
| |
Now, a 'build' block can override any special binding like 'command'
or 'description' if it needs to.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The build log is needed in computing whether an edge is
dirty, so I think it belongs here. (It's a bit weird
that Builder needs to reach into it to record completed
commands, maybe it will become cleaner with more thought.)
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix a compilation error.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I think I had originally imagined StatCache would contain more state,
but at this point it's clear it was just managing a single map, which
could just as well be in the already-small State object.
|
|
|
|
|
|
| |
The two were always one-to-one anyway. I started adding accessors
to FileStat and then realized most users wanted them on Node and
that forwarding them through was silly.
|
|
|
|
|
|
|
|
|
|
|
| |
1. For targets, when invoking ninja to build a target.
2. For targets, when doing a "query" command.
3. For command names.
4. For the subcommands of the "targets" command.
Also change CmdTargets() to call LookupNode() instead of GetNode() --
since the result was checked for NULL, that's probably what was intended
here originally.
|
|
|
|
|
| |
dirty_ is intended to remain static during the build (unless a restat
occurs), while outputs_ready_ reflects the dynamic state of the build.
|
|
This was a TODO in src/ninja_jumble.cc. Now this task is completed.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|