| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
'$:' is a valid string now, it expands to ':'
update error messages and show a hint when something went wrong.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Fixes the other half of issue #187.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- Delete the old "Tokenizer" code.
- Write separate tests for the lexer distinct from the parser.
- Switch the parser to use the new code.
- New lexer error output has file:line numbers so e.g. Emacs can
jump your editor to the syntax error.
- The EvalEnv ($-interpolation) code is now part of the lexer as well.
|
| |\
| |
| | |
Escape spaces
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
| |
Rather than nested tests, use a table. Shaves 200ms off Chrome null startup.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
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 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.
|
| |
|
|
|
|
| |
This speeds up the common case (where you don't need a line number)
at the small expense of the uncommon case (for error messages, you
do need a line number). And it's less code.
|
| |
|
|
|
| |
This means that backslashes are passed through without interpretation,
allowing us to support Windows paths without worrying about escaping.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Instead, parse them as normal words, which makes them work as paths.
We instead rely on the *position* (i.e., we start a statement with a
keyword and not a path) to distinguish the keyword 'build' from the file
'build'.
|
| |\
| |
| | |
Minor bug fix
|
| | |
| |
| |
| |
| |
| | |
It make it easier while debugging to know who is reporting the error:
Ninja itself or one of the command called by Ninja during the build
process or one of the generator which called Ninja.
|
| |/
|
|
|
| |
E.g. when parsing "foo = ${bar", point at the correct location of
the missing curly brace.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
