| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
