| 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
|
|
|
|
| |
This is step 4 on #931.
|
|
|
|
| |
header files
|
| |
|
|
|
|
|
|
| |
Allow rules or build statements to specify one of the build statement
inputs in a "dyndep" binding. This will later be used to load
dependency information from the specified file.
|
|
|
|
|
|
|
|
|
|
| |
Lexer::ReadIdent() now sets last_token_ before returning, like
Lexer::ReadEvalString() does. So all "expected identifiers" and things
that call ReadIdent (pool parser, rule parser, let parser, code parsing
the rule name after a : in a build line) now point the "^ near here" at
what was there instead of the previous last_token
According to manifest_parser_perftest, this is perf-neutral.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This will allow more options to be added without updating everywhere
that constructs a ManifestParser. Also extend the AssertParse function
to take the options so tests can control them.
|
|
|
|
|
|
|
|
|
|
| |
There is a class of commands that take an output directory where
they create their output files. Among them are cp(1), tar(1) to name a
few. These commands have one or more implicit outputs but no explicit
output.
With this patch, Ninja's parser accepts build edge with an
empty list of explicit outputs.
|
|
|
|
|
|
|
|
| |
Sadly, duplicate outputs aren't an error by default in Ninja (see also
a new edge has no effect. Remember to decrement the "number of
implicit outputs" counter for the new edge when this happens.
Fixes #1136.
|
|
|
|
|
|
|
|
|
| |
Visual C++ 2015 warns if a local variable hides visibility of another variable
in a higher scope. Since this project declares warnings as errors, ninja_test
simply won't build on Visual C++ 2015.
The variables have been renamed and scope limited as appropriate, so that
ninja_test will build without error now on Visual C++ 2015.
|
|\
| |
| | |
Add support for build statement implicit outputs
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
| |
Avoid having two separate filesystem interfaces. Simplify test
infrastructure by avoiding custom `ManifestParser::FileReader`
implementations.
|
| |
|
| |
|
|
|
|
|
| |
This is step 1 on #931. Duplicated edges will become an error by default in
the future.
|
|
|
|
|
|
|
|
|
|
|
| |
Patch #933 fixed a crash with duplicate edges by not adding edges to the
graph if all the edge's outputs are already built by other edges.
However, it added the edge to the out_edges of the edge's input nodes
before deleting it, letting inputs refer to dead edges.
To fix, move the check for deleting an edge above the code that adds
inputs. Expand VerifyGraph() to check that nodes don't refer to edges
that aren't present in the state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
The new test shows the added value of scoped rules by demonstrating
a multi-level build where a single rules file gets included at all
the levels. By scoping rules, this is possible.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Use a small, standalone testing framework for ninja instead of googletest.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/ |
|
|
|
|
|
|
| |
In summary: don’t escape if the path doesn’t contain problematic characters, otherwise:
- Shell: enclose string in single quotes, escape embedded single quotes with the magic quote-backslash-quote sequence
- Win32: Escape double quotes by doubling the number of consecutive backslashes that precede them (if any) and adding one more. Finally, double the number of trailing backslashes, and enclose the whole thing in double quotes.
|
| |
|
|\
| |
| | |
Fix diagnostic formatting regression caused by adaa91a33eb2cf23b88.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Ninja regressed to include a location for every file on the include stack for
nested diagnostics, i.e. it would print:
input:1: include.ninja:1: expected path
Fix this so that it prints only the current file location, like it used to:
include.ninja:1: expected path
Also add a test for this.
|
|/ |
|
|
|
|
|
| |
Also add more tests for invalid manifests. According to gcov, these invalid
inputs weren't tested before.
|
| |
|
|
|
|
| |
We "using namespace std" anywhere we need a std::string or a std::vector.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The constructor does
env_ = &state->bindings_;
so env_ is effectively set to offsetof(ManifestParser, bindings_). This
will blow up if env_ gets dereferenced -- this doesn't seem to happen in
these tests, but it's less confusing with this patch. Also, passing &state is
consistent with the rest of this test.
|
|
|
|
|
| |
Now, a 'build' block can override any special binding like 'command'
or 'description' if it needs to.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out to be trickier than expected to process these correctly.
It turns out to also be trickier than expected to give a nice error
message on encountering these. But the behavior prior to this patch
would just be silent failures where we attempted to examine paths
that accidentally contained embedded \r.
For now, fix all regexes of the form [^...] to include \r in the
excluded block, then assert that we get a vague lexer error near the
problem.
In the future perhaps we can open manifest files in text mode on Windows
or just disallow Windows-style CRLF in the manual.
|
|
So it matches with the class name in there.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|