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.
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>
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.
* 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.
- 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.
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>
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.
