| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Fix triggered warnings:
- unused parameter
- type qualifiers ignored on function return type
- missing initializer for member
|
| |
|
| |
|
|
|
|
|
|
|
| |
GetProcessId() is available only since Windows XP. Since
MinGW define WINVER to 0x0400 which is Windows 2000 I think, we have
a compilation error. Using GetCurrentProcessId() instead of
GetProcessId(GetCurrentProcess()) fix this issue.
|
|
|
|
|
|
|
|
|
|
|
| |
1. For targets, when invoking ninja to build a target.
2. For targets, when doing a "query" command.
3. For command names.
4. For the subcommands of the "targets" command.
Also change CmdTargets() to call LookupNode() instead of GetNode() --
since the result was checked for NULL, that's probably what was intended
here originally.
|
|
|
|
| |
llvm/lib/Support/StringRef.cpp.
|
|\
| |
| | |
Minor code change to address a warning in g++ 4.6.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This tool performs a post-order traversal of the build graph, starting
from a list of targets specified on the command line, and for each
build statement encountered, prints the evaluated command line.
Use cases include:
- Generating input for a tool which needs to know the full command line
for every command invoked during a build. Many static analysis
and indexing tools require this information.
- Generating a build script which does not depend on Ninja.
For example, such a script could be used by Ninja to bootstrap
itself.
|
|\ \
| | |
| | | |
CMake requirements: Make-style order-only dependencies, restat rules
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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).
|
| | |
| | |
| | |
| | |
| | | |
This permits us to write tests that write and later read from
the build log without needing a temporary log file.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |
| |
| |
| | |
Patch from Antoine Labour <piman@chromium.org>, (hacky) test by me.
|
|/ |
|
|
|
|
|
|
| |
Since we have started using command line flags for the clean tool, it
is inconsistent to keep the "target" and "rule" prefixes. Replace them
with a "-r" flag with the same semantics as "rule".
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When building projects with long file paths, the rule name may
disappear since the output is elided on the left side.
So you no longer know whether you are compiling or linking.
I think the user is interested in both the rule name and the file name.
Eliding the output in the middle solves this problem.
|
|
|
|
| |
Fixes part of issue 121, but the fix exposed a further issue.
|
|
|
|
| |
e.g. "ninja src/graph.cc^" builds the object file generated from that input
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
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.
|
|/ |
|
|
|
|
|
|
| |
Refactor the code in StatCache for use in BuildLog. Now both use
hash tables where the keys are const char*. Removes another 30ms
from Chrome no-op builds.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
| |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|\
| |
| | |
This is C++, there is no need to write 'struct' before the type when decl
|
| |
| |
| |
| |
| |
| | |
declaring a variable.
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
| |
| |
| |
| |
| | |
This has a small (20ms) effect on Chrome, but it will also be used
more as I remove more strings.
|
| |
| |
| |
| | |
Rather than nested tests, use a table. Shaves 200ms off Chrome null startup.
|
| | |
|
| |
| |
| |
| | |
Fixes issue #85.
|
| | |
|
|/
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Make Cleaner::config_ a reference-to-const instead of copying the value.
|
| |
| |
| |
| | |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|\ \
| |/
|/| |
Add depfile support to build command with multiple outputs (Fixes: #61)
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.]
|
| |
| |
| |
| | |
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|
|\ \
| | |
| | | |
Fix windows build by moving mkdtemp() implementation from ninja_test.cc t
|
| | |
| | |
| | |
| | |
| | |
| | | |
disk_interface_test.cc
Signed-off-by: Thiago Farina <tfarina@chromium.org>
|