| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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.
|
| | |
|
|/
|
|
|
|
|
|
| |
Ninja does resolve relative paths and file system links in paths.
Therefore, such paths pointing to the same file will not match and may
lead to an invalid dependency graph.
Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
|
| |
|
|\
| |
| | |
Document target^ syntax.
|
| |
| |
| |
| | |
Added a note into the documentation about interesting target^ syntax
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #730. This has always been broken, but due to #690 more paths are now
escaped (e.g. paths containing + characters, like file.c++). Also see
discussion in #689.
The approach is to give EdgeEnv an enum deciding on whether or not to escape
file names, and provide functions that evaluate depfile and rspfile with that
set that to kNoEscape. (depfile=$out.d doesn't make sense on edges with
multiple outputs.)
This should be relatively safe, as $in and $out can't be used on edges, only
on rules (#687).
|
| |
|
|
|
|
|
|
|
| |
This is a pre-defined pool with a depth of 1. It has the special property
that any task in the pool has direct access to the console. This can be
useful for interactive tasks or long-running tasks which produce status
updates on the console (such as test suites).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The earlier section is a tutorial-style overview. The latter section
is for side features like phony rules and header dependencies. Pools
fit in with the latter.
|