| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
will prevent useless conversions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
See the comment 5 lines up for details.
|
| |
|
|
| |
Also add a test for this case, which would have spotted the issue too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |\
| |
| | |
Proposed/deps log write errors checking
|
| | | |
|
| | | |
|
| |/
|
|
| |
This is useful for performance comparisons between two build directories.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When two ninja instances run in parallel in the same build directory,
one instance could write a deps entry header and a few ids, and then the
other instance could write a file name in the middle of the deps header.
When ninja reads this deps log on the next run, it will deserialize the
file name as indices, which will cause an out-of-bounds read.
(This can happen if a user runs a "compile this file" that uses ninja to
compile the current buffer in an editor, and also does a full build in a
terminal at the same time for example.)
While running two ninja instances in parallel in the same build
directory isn't a good idea, it happens to mostly work in non-deps mode:
There's redundant edge execution, but nothing crashes. This is partially
because the command log is line-buffered and a single log entry only
consists of a single line.
This change makes sure that deps entries are always written in one go,
like command log entries currently are. Running two ninja binaries in
parallel on the same build directory still isn't a great idea, but it's
less likely to lead to crashes.
See issue #595.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Previously, a DepsLog would become invalid after Recompact() was called,
due to Recompact() making all node ids refer to a temporary DepsLog
object constructed in Recompact().
|
| |
|
|
|
|
| |
This is a behavior change, but it should be safe: Graph only queries the
deps log at startup, before running any command. Nothing else currently
queries the deps log.
|
| |
|
|
| |
No functionality change.
|
| |
|
|
| |
No functionality change.
|
| |\
| |
| | |
Introduce a Truncate() function that works on POSIX and Windows.
|
| | |
| |
| |
| | |
Hopefully fixes the build on Windows.
|
| |\ \
| | |
| | | |
Make sure that recompaction writes a pristine new depslog.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
...even if a prior run of DepsLog::Recompact() exited without cleaning
up, for example due to a crash or because someone added a `return true;`
in the middle of the function while debugging. Or because someone hits
ctrl-c during deps log recompaction.
No test, because I can't think of a way to trigger this scenario
programmatically.
Part of issue #554.
|
| |/
|
|
| |
Part of issue #554.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If a read fails while reading an entry, truncate the log to the last
successfully read entry. This prevents corruption when a subsequent
run appends another entry.
|
| |\
| |
| | |
fix windows build after depslog
|
| | | |
|
| |/
|
|
| |
Also add tests for invalid headers.
|
| |
|
|
|
|
| |
This way, it doubles as a byte-order marker. The header is now exactly one
line in a hex editor, and it's still relatively easy to look at the version
in a text editor.
|
| |
|
|
| |
It touched the various remaining XXXes in the code, hooray.
|
| |
|
|
| |
Fixes a gcc debug-mode assertion.
|
| | |
|
| | |
|
| |
|
|
| |
Not done automatically yet, just an implementation and a test.
|
| | |
|
| |
|
|
| |
Future-proofing against some change we may need to make later.
|
| |
|
|
| |
Shortcuts a common case.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
WIP
|
