| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Recompacting the build log used to be slow, so it made sense to print this
message. We then made recompaction much faster, but didn't remove this
message back then.
The deps log only has it because the build log had it.
Since both steps are effectively instant in practice, remove these log messages.
|
|
|
|
| |
Now tests don't print anything. Non-test behavior is unchanged.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For .ninja_deps, remove objects that have no in-edges or whose in-edges
do not have a "deps" attribute. (This matches the behaviour of `-t
deps`).
BuildLog doesn't know about state, so let its recompact method take
delegate that decides is a path is life or not, and implement it in
NinjaMain.
|
| |
|
|
|
|
| |
Like f6f00aa40f0c541df06, but for the build log instead of the deps log.
|
|\
| |
| | |
Add a 'recompact' tool, which forces recompaction of the build and deps ...
|
| |
| |
| |
| | |
This is useful for performance comparisons between two build directories.
|
|/
|
|
| |
architectures like OpenBSD/mips64el and OpenBSD/hppa64.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
(Committing this on top of b56fe80 since they're related,
but I may end up reverting both.)
|
| |
|
|
|
|
|
|
| |
This reverts commit 904c9610fe66c4f4bd63a07d6f057c8603d24394.
The commit caused issue #380, this revert fixes it. The revert
also makes the test from the previous commit pass.
|
|\
| |
| | |
Make StringPiece data members private.
|
| |
| |
| |
| | |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
| |
| |
| | |
Not a real problem, mainly to make valgrind happy
|
|/ |
|
|
|
|
|
|
| |
Nico convinced me that it's safe to do this without revving the build
log format: the old decimal values will still parse as hex (just as
different numbers) and cause a superfluous rebuild.
|
|
|
|
|
| |
Log format 4 was introduced in January.
There's been plenty of time to migrate.
|
|
|
|
| |
Fixes a warning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.build_log load time 350ms -> 17ms, filesize 197MB -> 1.6MB on
Mac. On Windows, it's 500ms -> 20ms.
Makes the build log a lot less useful for scripts, but there could
be a tool for use cases that need log information. A prototype of
such a tool is in https://github.com/nico/ninja/commit/1b243d311
The hash function is 64bit murmurhash2. Assuming that that different
commands get the same hash only by chance, it's is very unlikely
for two different commands to hash to the same value with a 64bit
hash.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fgets() needs to search for a \n in the input, and LineReader's
strstr() did the same work again. By using fread() directly, this
duplicate work can be saved.
(I tried using readline() / fgetln() for the same saving, but those
functions are not standard, and were slower than the code in this CL.)
Results from running build_log_perftest, on OS X:
Before: min 369ms max 372ms avg 370.4ms
After: min 243ms max 247ms avg 244.8ms
On Windows:
Before: min 796ms max 904ms avg 858.0ms
After: min 359ms max 375ms avg 371.4ms
On Linux:
Before: min 161ms max 169ms avg 164.8ms
Before: min 130ms max 137ms avg 132.6ms
|
|
|
|
| |
change.
|
| |
|
|\
| |
| | |
Add .ninja_log load time to metrics.
|
| |
| |
| |
| | |
On my system, it takes 22% of the empty build time for chrome.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The MSVC std::string implementation copies strings, so using make_pair
resulted in a pointer to invalid memory. This ensures the insert uses a
StringPiece without an intermediate std::string copy, so the correct pointer
ends up in the hash_map.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
spaces.
|
|
|
|
|
|
|
|
|
| |
They are not accessed outside of BuildLog and there is even a SetConfig function
to set the |config_| variable.
So better to make them private to BuildLog now while nobody is using it outside.
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.
|
|\
| |
| | |
CMake requirements: Make-style order-only dependencies, restat rules
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |
| |
| |
| |
| | |
This permits us to write tests that write and later read from
the build log without needing a temporary log file.
|