| 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.
|
| |
|
|
|
| |
Elsewhere in the code I avoid sstream and manual buffer management,
so switch this code to behave similarly. Sorry for being OCD.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Even if such a target is dirty (i.e. the file does not exist), it
has nothing to do, which makes it safe to mark as outputs-ready.
Without this change, ninja will print no output when rebuilding the
target (or an order-only dependency thereof), instead of reporting
it has "no work to do".
|
| |
|
|
|
|
|
| |
Specifically, only delete if the file was modified or if the rule uses
a depfile.
Fixes issue #226.
|
| |\
| |
| | |
Response files
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
| |
Rather than mixing use of WIN32 and _WIN32.
|
| |
|
|
| |
cleaned) and a fix for this
|
| |
|
|
|
|
|
| |
If a restat rule claims to write an output but doesn't, consider it
"no change" (in the restat sense) if the output didn't exist beforehand.
I.e. if the output didn't exist before and the output doesn't exist after,
we don't need to run dependent rules.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The two were always one-to-one anyway. I started adding accessors
to FileStat and then realized most users wanted them on Node and
that forwarding them through was silly.
|
| | |
|
| |
|
|
| |
It was firing too often, and hadn't uncovered any bugs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic before was like:
for each output:
if edge_dirty or output.dirty:
output.dirty = true
edge_dirty = true
This was wrong in the case where the second output would case the edge
to be dirty; we needed to go back and mark the first output dirty as
well. Fixed by taking two passes: one to compute the dirty state,
then a latter sweep to mark all outputs.
Fixes issue 148.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the implementation of order-only dependencies differed
between Make and Ninja in two important ways:
1) If the order-only dependency existed but was out of date, it
would never be rebuilt, whereas Make would always rebuild out of
date order-only dependencies.
2) If the order-only dependency did not exist, it would cause
its reverse dependencies to always build, whereas Make would only
rebuild a file if a non-order-only dependency was out of date.
A key distinction between Ninja and Make as seen through the above
two points was that in Ninja, order-only dependencies cared about
whether the target as a file exists (so perhaps a better name for
the old semantics would have been "missing-only dependencies").
These differences made it impossible to introduce an order-only
dependency on an always out-of-date (i.e. missing) target without
also causing the depender and its reverse dependencies to rebuild
unnecessarily on every build. Build systems which must perform some
action (such as logging the build start time, or printing a message)
at the start of every build typically implement this by adding to
every target an order-only dependency which performs this action,
which would have forced an entire rebuild on every invocation of
Ninja under the old semantics.
This commit causes Ninja to conform to the Make-style behaviour.
|
| |
|
|
|
| |
dirty_ is intended to remain static during the build (unless a restat
occurs), while outputs_ready_ reflects the dynamic state of the build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 639c8f0 ("don't mark phony edges dirty if none of their
inputs are dirty") modified the behaviour of the "phony" built-in
rule. Previously, when the output file was missing, it was marked
as dirty. After 639c8f0, it was always marked as clean unless one
of the dependencies was dirty. The depfile mechanism uses the old
behaviour of "phony" to rebuild an object file if any of the headers
were missing.
Restore the old "phony" behaviour only for the case where the build
statement has no dependencies. This is slightly inconsistent, but I
can't really see any other use case for an alias of nothing. Also,
document this behaviour.
|
| | |
|
| |
|
|
|
|
|
| |
Because the output file is always missing, we'd consider a phony edge
dirty even when there wasn't any work to do. Most importantly, that
would mean we wouldn't print "nothing to do" in the common case of
everything being up to date when building an alias.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now it does. Still works as it should on linux too.
The canonical example that now works on Windows is:
builddir = build
rule copy
command = copy $in $out
build $builddir\fred\test.out: copy test.in
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Edges found through depfiles are special: they get an extra
empty "phony" rule. (This is identical to the way you hack this
with Makefiles.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
