| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Rather than passing States and DiskInterfaces through all the calls,
put the necessary ambient information in a new DependencyScan object
and move the code accordingly.
Note: I didn't move the source location of the functions to preserve
history, though this does result in a sort of weird order for the
functions in graph.cc.
|
| | |
|
| |
|
|
|
|
|
| |
- Edge::Dump could crash if called while inputs_ is being extended
- Node::Dump prints Node attributes, in-edge and lists of out-edges
- Dump functions now accept "prefix" parameter, printed along with the object
for easier orientation. For example, edge->Dump("Re-reading deps files").
|
| |
|
|
|
|
|
|
| |
This was reported by cpplint as:
python ~/depot_tools/cpplint.py 2>&1 | grep -v "Done processing" | grep explicit
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| | |
|
| | |
|
| |\
| |
| | |
Response files
|
| | | |
|
| | | |
|
| |/
|
|
| |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| | |
|
| |
|
|
| |
Reported by clang++.
|
| |
|
|
|
|
|
|
|
| |
- Delete the old "Tokenizer" code.
- Write separate tests for the lexer distinct from the parser.
- Switch the parser to use the new code.
- New lexer error output has file:line numbers so e.g. Emacs can
jump your editor to the syntax error.
- The EvalEnv ($-interpolation) code is now part of the lexer as well.
|
| |
|
|
| |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
|
|
|
|
| |
Move various data members to private section and provide accessors for them.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Rather than taking whether the edge is dirty as an input, instead
only consider the arguments and return true/false, allowing the caller
to decide what to do with that information. (In the restat case we
were faking out the environment to get particular behavior for this.)
Should have no side effects, but this is part of fixing issue 148.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A restat rule is a rule which is capable of pruning the build tree
depending on the timestamps of its outputs before and after a build.
After a restat rule is rebuilt, Ninja will re-stat each output file
to obtain its current timestamp. If the timestamp is unchanged from
when Ninja initially stat'ed the file before starting the build,
Ninja will mark that output file as clean, and recursively for each
reverse dependency of the output file, recompute its dirty status.
Ninja then stores the most recent timestamp of any input file in the
build log entry associated with the output file. This timestamp
will be treated by future invocations of Ninja as the output file's
modification time instead of the output file's actual modification
time for the purpose of deciding whether it is dirty (but not whether
its reverse dependencies are dirty).
|
| |
|
|
|
| |
dirty_ is intended to remain static during the build (unless a restat
occurs), while outputs_ready_ reflects the dynamic state of the build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a rule attribute "generator" which, if present, specifies
that this rule is used to re-invoke the generator program. Files built
using generator rules are treated specially in two ways: firstly,
they will not be rebuilt if the command line changes; and secondly,
they are not cleaned by default.
A command line flag "-g" is introduced for the clean tool, which
causes it to remove generator files.
Fixes issue #102.
|
| | |
|
| |
|
|
|
|
| |
Also add util_test.cc and move the CanonicalizePathTest into there.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
|
|
|
|
|
|
|
| |
If a C file #includes "../foo.cc", then gcc will emit paths like
"bar/../foo.cc" into the dependency file; canonicalize these when we
load the file.
Add a test module for testing the graph dirty recomputation directly,
without all the build classes around it.
|
| | |
|
| | |
|
| | |
|
| |
|
