| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Read and write the timestamp as two separate 32-bit integers in a fixed
order to prevent any issues with alignment or byte order.
|
| |
|
|
| |
This prepares it for higher-resolution timestamps.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two bugs.
1.) It makes the record size field 4 byte instead of 2, and allows a max
record size of 512kB. This fixes #605, ninja "only" supporting 8k
dependencies per file -- 512kB have room for 128k dependencies. (If that's
still not enough, the current design can support at least 4x that if the
constant is tweaked.)
2.) It makes all records 4-byte aligned, which is probably needed to make the
`reinterpret_cast<int*>(buf)` work on SPARC (cf issue #481), and it's
generally nicer too. (Since there's already one reinterpret_cast, convert
a memcpy() to reinterpret_cast in another branch too).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ninja assumes that numbering path entries in the deps log in order produces
valid dense integer ids. If two ninja processes write to the same deps log
concurrently, this is not true. Store the expected indices of path records
in the log and treat the rest of a deps log as invalid if the dense id of a
path record doesn't match the expected id stored in the log. Addresses the
rest of issue #595.
This requires bumping the deps log file format version. Do not migrate the
old version to the new, as the old format did not have this protection, and
might hence contain invalid data. (Unlikely, but possible.)
Also store the record id as one's complement, to make them look less like
regular deps record values. Since each record is written atomically this
isn't really necessary, but it makes the format somewhat more robust (and
easier to read in a hex editor).
|
| |
|
|
|
| |
Now that Recompact() keeps all data structures intact, it can just be
called at the beginning of a build and the build will still work.
|
| |
|
|
| |
No functionality change.
|
| |
|
|
| |
No functionality change.
|
| |
|
|
|
| |
This doesn't yet exhibit the full problems with truncation, but it's
a start.
|
| |
|
|
| |
It touched the various remaining XXXes in the code, hooray.
|
| | |
|
| |
|
|
| |
Not done automatically yet, just an implementation and a test.
|
| | |
|
| | |
|
| |
|
|
| |
WIP
|
|
|
DepsLog is a compact serialization of dependency information.
It can be used to replace depfiles for faster loading.
|
