| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
My goals were:
- shorten the introductory text, hopefully quickly answering the "why?"
question first.
- put the information relevant to ninja users (e.g. people using CMake
who don't especially care about ninja) next, at the beginning.
- consolidate the "generating ninja files" text below.
|
| | |
|
| |\
| |
| | |
Minor Documentation Tweak
|
| | | |
|
| |/
|
|
|
|
| |
Some people may want to display different relevant information about
the progress of the build. Also it can be usefull to debug jobs
allocation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| | |
Support for rebuilding and reloading manifest files
|
| | |
| |
| |
| |
| |
| | |
This introduces support for rebuilding the top-level manifest file
using a provided build statement, and reloading it before building
the user-requested targets.
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
This introduces a new directive, the default target statement, which
may be used to control the list of targets built by default (i.e. if
no target is named on the command line).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This means that backslashes are passed through without interpretation,
allowing us to support Windows paths without worrying about escaping.
|
| | |
|
| |
|
