| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Edges are nominally ordered by order in the build manifest, but in
fact are ordered by memory address. In most cases the memory address
will be monontonically increasing. Since serialized build output will
need unique IDs, add a monotonically increasing ID to edges, and use
that for sorting instead of memory address.
|
|
|
|
| |
symbols
|
| |
|
|
|
|
| |
The VS compiler complained about possible loss of data (and it was right!)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This will make it easier to optionally make this an error (because
ManifestParser has a way of printing errors), and it'll also make
it easier to make the tests quiet again.
No behavior change.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This function was added at 307f0bbd("and some basic implementation"), but nobody
calls it anymore.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
| |
https://github.com/martine/ninja/issues/358
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|
|
|
| |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|