| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The build log is needed in computing whether an edge is
dirty, so I think it belongs here. (It's a bit weird
that Builder needs to reach into it to record completed
commands, maybe it will become cleaner with more thought.)
|
| |
|
|
|
|
|
|
|
|
| |
Rather than passing States and DiskInterfaces through all the calls,
put the necessary ambient information in a new DependencyScan object
and move the code accordingly.
Note: I didn't move the source location of the functions to preserve
history, though this does result in a sort of weird order for the
functions in graph.cc.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes issue #392 (didn't handle creating nested build dirs right).
Moves MakeDir out of util.h; all code should go through
DiskInterface to simplify testing. Moves ownership of the
DiskInterface into the client of the Builder, which also allows
removing some code that reached inside the object as well as
a minor leak.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
prints the rate of finished edges per second to the console,
for instance with NINJA_STATUS="[%s/%t %o(%c)/s] ":
[132/1922 16.1(14)/s]
16.1 is the average for all processed files (here 132 since start)
14 is the average of the last n files while n is the number specifies by
-j (or its default)
|
| |\
| |
| | |
No need to write 'struct' before type name when declaraing variables in ...
|
| | |
| |
| |
| | |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |/ |
|
| |
|
|
|
|
|
|
| |
This was reported by cpplint as:
python ~/depot_tools/cpplint.py 2>&1 | grep -v "Done processing" | grep explicit
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| | |
|
| |\
| |
| | |
Max load average
|
| | |
| |
| |
| |
| |
| |
| | |
This is similar to GNU make -l/--load-average option. It limits the number
of job started if the load average exceed the given value. It can be very
useful when running ninja on a continuous integration server where we want
to use parallelism as much as possible without overloading the server.
|
| | |
| |
| |
| |
| | |
Elsewhere in the code I avoid sstream and manual buffer management,
so switch this code to behave similarly. Sorry for being OCD.
|
| |/ |
|
| |
|
|
|
|
|
| |
Specifically, only delete if the file was modified or if the rule uses
a depfile.
Fixes issue #226.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if a command fails, the fate of the other child processes
running in parallel was inadequately controlled. On POSIX platforms,
the processes were orphaned. Normally they would run to completion,
but were liable to being killed by a SIGPIPE. On Windows, the child
processes would terminate with the parent. The cleanup-on-interrupt
patch caused the SubprocessSet and Builder destructors to clean
up after themselves by killing any running child processes and
deleting their output files, making the behaviour more predictable
and consistent across platforms.
If the build is interrupted by the user, this is correct behaviour.
But in the case where the build is stopped by a failed command, this
would be inconsistent with user expectations. In the latter case,
we now let any remaining child processes run to completion before
leaving the main loop in Builder::Build.
|
| |
|
|
|
|
|
|
| |
This causes us to clean up by deleting any output files belonging
to currently-running commands before we quit if we are interrupted
(either by Ctrl-C or by a command failing).
Fixes issue #110.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
dirty_ is intended to remain static during the build (unless a restat
occurs), while outputs_ready_ reflects the dynamic state of the build.
|
| |
|
|
|
|
|
| |
Don't rebuild the manifest when it's already up to date.
The underlying problem was that Builder::Build has a confusing API;
split the API so it's more clear for callers what the return values
mean.
|
| |
|
|
|
| |
After much staring at this I think I found the more clear way to
express what it's doing.
|
| |
|
|
|
|
| |
Centralizing printing allows being more careful about what is output.
1) Always include the [2/15] prefix on commands.
2) Make the header command match the error output command.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
