| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Add 'inputs' tool to print out all inputs for a set of targets
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Add validation nodes to ninja
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A common problem in the Android build is inserting rules that perform
some sort of error checking that doesn't produce any artifacts needed
by the build, for example static analysis tools. There are a few
patterns currently used, both of which have downsides.
The first is to have a rule that depends on all of the static analysis
results. This ensures they run, but requires running static analysis
over everything, and not just the active parts of the build graph.
The second is to insert the static analysis rule into the build graph
between the artifact producing rule and anything that depends on it,
often copying the artifact as the output of the static analysis rule.
This increases the critical path of the build, often reducing
parallelism. In the case of copying the artifact, it also wastes
disk space.
This patch adds "validation nodes" to edges in Ninja. A build
statement can specify validation nodes using "|@" in the edge
inputs. The validation nodes are not used as an input to the edge
(the edge can run before the validation node is ready), but are
added to the initial nodes of the build graph whenever the edge
is part of the build graph. The edge that outputs the validation
node can depend on the output of the edge that is being validated
if desired.
Test: ninja_test
Change-Id: Ife27086c50c1b257a26509373199664680b2b247
|
|\ \ \
| | | |
| | | | |
NF: clarify documentation's part about rules description
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The word "eventually" was quite strange here and should probably removed. I
suspect "potentially" was meant (which in French is "eventuellement", a standard
false friend). In any way, after a quick look at the source/ninja message, I
chose to even clarify this part of the doc, indicating that the `-d` option is
required here.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit fixes issue #478.
Observed:
Real edges depending on a phony edge will not be marked as dirty or
rebuilt if the phony's (real) inputs are updated.
Expected:
An edge should always be rebuilt if its inputs or transitive inputs are
newer than the output's mtime.
Change:
Node::mtime_ was overloaded, 0 represented "does not exist". This change
disambiguates it by adding Node::exists_. Then to fix the observed
behaviour, Node::UpdatePhonyMtime was added to update the mtime if the
node does not exist.
Add tests BuildTest.PhonyUseCase# GraphTest.PhonyDepsMtimes.
Unit tests will also test for always-dirty behaviour if a phony rule has
no inputs.
|
|\ \
| | |
| | | |
Clarify purpose for implicit dependencies
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The ANSI code page identifier is more information than generator
programs actually need. The encoding of `build.ninja` is always
either UTF-8 or the system-wide ANSI code page. Reduce the output
to provide no more information than the generator programs need.
The Console code page can be obtained in other ways, so drop it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since commit 00459e2b (Use UTF-8 on Windows 10 Version 1903, fix #1195,
2021-02-17), `ninja` does not always expect `build.ninja` to be encoded
in the system's ANSI code page. The expected encoding now depends on
how `ninja` is built and the version of Windows on which it is running.
Add a `-t wincodepage` tool that generators can use to ask `ninja`
what encoding it expects.
Issue: #1195
|
| | |
| | |
| | |
| | | |
Group all the paragraphs together in the definition list entry.
|
|/ / |
|
|/ |
|
|
|
|
| |
Nothing else describes what a "manifest" is in user-facing docs.
|
|\
| |
| | |
Recommend MD over MMD for header dependencies.
|
| |
| |
| | |
The MMD flag will silently omit includes found through pointy brackets or system include paths. This can lead to issues not only when system headers change, but any paths included through the isystem flag. Because the isystem flag implicitly turns off warnings as errors it has often come to be used as a "not my code" flag used with local third party dependencies which may be frequently updated or changed for debugging. As a result, it is far safer to default to MD (which includes all include dependencies) in this example.
|
| | |
|
|/ |
|
|\
| |
| | |
Describe how to make a phony rule always up to date
|
| |
| |
| |
| |
| |
| |
| | |
A phony rule with no input is always out of date. Describe how to make a
rule always up to date.
Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This tool is useful for writing shell completion script for tools
expecting a rule name as argument.
The tool was dropped by 34b46f28c.
Fix #1024.
|
| |
| |
| |
| |
| |
| | |
Show a simple example of Fortran module dependencies (this use case
motivated the entire dyndep feature). Also show an example of tarball
extraction, a case that few other buildsystems can handle cleanly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Change gyp to gn
|
| | |
| | |
| | |
| | |
| | | |
Chrome has switched from gyp to gn, and Fuschia also uses it now.
Note that the "Chromium Ninja documentation" link is dead, but I'm not sure what to replace it with. The closest I've found is https://chromium.googlesource.com/experimental/chromium/src/+/refs/wip/bajones/webvr/docs/ninja_build.md, but I'm not sure that's the original intended target.
|
|\ \ \
| | | |
| | | | |
Win32 invalid parameter help
|
| |/ /
| | |
| | |
| | |
| | | |
This happens often enough and the error message is quite unhelpful.
Mention this error explicitly in the documentation.
|
|/ / |
|
| | |
|
|/
|
| |
The `deps` tool in particular is very useful to know about.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #999 changed the status line to be printed when edges finish on dumb
teerminals, but the default status message includes the number of
started edges, resulting in sequential status lines with identical
edge counts.
Change the default status to show the number of finished edges, which
will keep the count incrementing on every line. This will slightly
change the output on smart terminals. Previously a build that was just
starting would show a count equal to the number of concurrent jobs, and
a build waiting for the final jobs to finish would show a count equal to
the total number of edges. Now a starting build will show 0, and build
waiting for the final jobs will show a count less than the total number
of edges by the number of remaining jobs.
Fixes: #1142
|
|
|
|
|
|
|
| |
Add --port option to override the default port (8000).
Add --no-browser option to avoid opening a web browser (useful over
SSH).
Make the target name optional, using "all" if omitted.
|
| |
|
|\
| |
| | |
Minor updates to the manual.
|
| |
| |
| |
| |
| |
| |
| | |
* Update link to Chromium's ninja docs (fixes #1038)
* Update cmake URL to what it redirects to, and mention that ninja
is well-supported on all platforms in newer CMake versions.
* Let "others" link to the wiki page listing generators.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some build rules produce outputs that are not mentioned on the command
line but that should be part of the build graph. Such outputs should
not be named in the `$out` variable. Extend the build statement syntax
to support specification of implicit outputs using the syntax
`| out1 out2` after the explicit outputs and before the `:`.
For example, compilation of a Fortran source file `foo.f90` that defines
`MODULE FOO` may now be specified as:
rule fc
command = f95 -c $in -o $out
build foo.o | foo.mod: fc foo.f90
The `foo.mod` file is an implicit output generated by the compiler based
on the content of the source file and not mentioned on the command line.
|
|\
| |
| | |
use the default font size for manual headings
|
| |
| |
| |
| |
| |
| | |
The third-level subsection headings were almost indistinguishable
from the second-level ones. Fix this by just using the default
styling.
|
|\ \
| | |
| | | |
add a section to the manual discussion the command= variable
|
| |/
| |
| |
| |
| | |
This includes a mention of using cmd /c on Windows.
This would have helped on issue #1070 for example.
|
| |
| |
| |
| | |
The two columns of the table run together, making it hard to read.
|
| |
| |
| |
| |
| |
| | |
- Fix the manual build rules (missing the .xsl as an input).
- Add a README describing how the docs build works.
- Add rules that generate PDF, just 'cause we can.
|
| |
| |
| |
| | |
In particular, this helps web search engines index it.
|