| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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".
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
1) Add a system for recording detailed timing info of functions.
2) Add a -d flag for requesting debug info at runtime, with the
above as the first user.
|
| |
|
| |
|
|
|
|
| |
Add some comments as well.
|
|
|
|
|
|
| |
Move various data members to private section and provide accessors for them.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Rather than taking whether the edge is dirty as an input, instead
only consider the arguments and return true/false, allowing the caller
to decide what to do with that information. (In the restat case we
were faking out the environment to get particular behavior for this.)
Should have no side effects, but this is part of fixing 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a rule attribute "generator" which, if present, specifies
that this rule is used to re-invoke the generator program. Files built
using generator rules are treated specially in two ways: firstly,
they will not be rebuilt if the command line changes; and secondly,
they are not cleaned by default.
A command line flag "-g" is introduced for the clean tool, which
causes it to remove generator files.
Fixes issue #102.
|
|
|
|
| |
Fixes part of issue 121, but the fix exposed a further issue.
|
|\
| |
| | |
Allocate space in the inputs vector for the depfile implicit deps
|
| |
| |
| |
| | |
This speeds up a no-op LLVM/Clang build by about 20ms.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 of this, MakefileParser now returns pointers into the source
makefile string rather than allocating new strings. Despite needing
to take the result and stuff it into a new string anyway to canonicalize
it, this takes another 50ms or so off the null Chrome build, likely
due to the vector used in MakefileParser changing to a type that doesn't
use any allocations.
(I also experimented with making the vector reserve an initial size but
didn't see any performance impact.)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parsers.cpp: allow depfile used at build command with multiple outputs.
graph.cpp: allow depfile used at build command with multiple outputs.
parsers_test.cpp: make the test pass.
As before, the depfile itself can only mention one target, which must
be the first of a build command with multiple outpus.
[There is really no need to mention all the output in the depfile,
because all targets should depend on exactly the same files anyway,
because these targets are built by a single build command.]
|
|
|
|
|
|
| |
This was a TODO in src/ninja_jumble.cc. Now this task is completed.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|\
| |
| | |
Move RealDiskInterface class to disk_interface.h.
|
| |
| |
| |
| |
| |
| | |
This is a TODO in src/ninja_jumble.cc
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|/
|
|
|
|
|
|
|
|
|
| |
This allows generating build files in a subdirectory of your source tree.
- Change CanonicalizePath to accept this.
- CanonicalizePath no longer has an error condition, so change it to a void
function.
I profiled the result against Chrome and it might be ~100ms slower, but that
might just be Chrome's size working against me. In any case I think there
are lower-hanging performance fruit elsewhere.
|
|
|
|
|
| |
Make it return the correct value for "out" when there are multiple outputs.
It used to return only the first target file.
|
|
|
|
|
| |
I'm not sure this is semantically different but it's consistent with
how I think about these phony edges.
|
|
|
|
|
|
| |
Edges found through depfiles are special: they get an extra
empty "phony" rule. (This is identical to the way you hack this
with Makefiles.)
|
| |
|
|
|
|
|
|
| |
Also add util_test.cc and move the CanonicalizePathTest into there.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|
|
|
|
|
|
| |
This is just deleting some code that was written in anticipation
of staying memory-resident; when loading a depfile, we don't need
to attempt to update existing entries in the dependency list, we
just need to blindly add them.
|
|
|
|
|
|
|
|
|
| |
If a C file #includes "../foo.cc", then gcc will emit paths like
"bar/../foo.cc" into the dependency file; canonicalize these when we
load the file.
Add a test module for testing the graph dirty recomputation directly,
without all the build classes around it.
|
| |
|
| |
|
| |
|