| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.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.
|
|
|
|
|
|
| |
This fix the TODO in build_log.h file.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
| |
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 introduces support for rebuilding the top-level manifest file
using a provided build statement, and reloading it before building
the user-requested targets.
|
|
|
|
|
| |
In v2 we store both the start and end time of the command.
This allows better visualization of the build process.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|