| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Refactor the code in StatCache for use in BuildLog. Now both use
hash tables where the keys are const char*. Removes another 30ms
from Chrome no-op builds.
|
| |
|
|
|
| |
This has a small (20ms) effect on Chrome, but it will also be used
more as I remove more strings.
|
|
|
Note: This is a TODO in ninja_jumble.cc.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
