When a call to the Win32 API CreateProcessA fails, ninja
now outputs the exact command string that caused it to fail.
It also detects when the command contained leading whitespace
and outputs a hint that lets the user know why the command
failed.
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.
The option is called "depfile = gcc" and should support depfiles created
by GCC. GCC does not escape backslashes and GNU Make does not try to
unescape it, so neither should Ninja try to "unescape" it.
Only space (' ') and hash sign ('#') are specially treated by GCC/Clang.
Note that while tabs are also treated specially by GCC, Clang does not,
so do not special case it (why would someone use tabs in a filename?).
Support for 2N trailing backslashes in a filename is a bit questionable,
but is added to be as consistent as possible with GCC/Clang.
See also
44c160f916/lib/Frontend/DependencyFile.cpp (L316)22a8377023/libcpp/mkdeps.c (L47)
Fixes https://github.com/ninja-build/ninja/issues/1262
but are no longer produced by the current manifest. For now adding a dedicated
"-t cleandead" option, since it should be run after reading the log; ideally
it should be part of the build config and done before to start looking for
dirty targets so that an incremental build would produce the same end result
as a clean build from scratch. But since I am not 100% sure to understand the
comment in the NinjaMain::isPathDead(), I opted to make it a tool for now to
avoid impacting users who want to keep those files.
The option name "cleandead" was selected insteadof something like "reap" to
keep the "clean" prefix.
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.
Teach the `-t graph` tool to load dyndep files because they are part of
the build graph. Issue a warning when the dyndep file cannot be loaded
cleanly. This will help users visualize the complete build graph.
Some outputs may not be known in the main build manifest and are instead
discovered through a dyndep binding. Load dyndep files that are
available during cleaning so that we can clean these outputs too.
`Cleaner` provides two constructors that are the same except that one
constructs a "real" disk interface internally and the other takes a
caller-provided disk interface. A real disk interface is already
available at the only call site for the former constructor. Use it
directly and drop the unnecessary constructor variant.
After finishing an edge that produces a dyndep file, load the file and
update the build graph structure. Recompute the dirty state of all its
dependents and of newly reachable portions of the graph. Add edges to
the build plan that are discovered to be wanted. Finally, schedule
edges that are wanted and now ready to build.
The full readiness of a node that has a dyndep binding cannot be known
until after the dyndep file is loaded. If a dyndep file is ready while
constructing the build plan it can be loaded immediately so full
information can be used to decide whether anything needs to be built.
If a dyndep file is not ready while constructing the build plan then the
edges naming it cannot be ready either because the dyndep file is one of
their inputs. In this case we defer loading the dyndep file until the
build plan is being executed.
Allow rules or build statements to specify one of the build statement
inputs in a "dyndep" binding. This will later be used to load
dependency information from the specified file.
Define a file format suitable for specifying dynamically-discovered
dependency information for build edges. Design a format inspired by the
build manifest format and using the same lexer. Start with a required
format version specification followed by "build" statements that add
implicit inputs and outputs to existing edges.
Track for each Edge whether depfile information has been loaded using an
explicit flag. This will allow RecomputeDirty to be repeated for an
edge without loading deps again.
In order to later support dynamic updates to the build plan while
building, the Plan will need access to its Builder. Since this access
will be needed only for specific features we can avoid updating all Plan
constructions in the test suite by making this access optional.
Replace our single active edge pointer with a vector and add a
parameter that tests can set to limit the number of concurrent
edges. Set the default to 1 to preserve the current behavior.
Specific tests will be able to override it later to simulate
concurrent builds.
Add an 'err' string argument and return a boolean for success. Update
call sites to pass an 'err' string argument and check the return value.
This will be useful later for adding logic to these methods that may
fail.
Create a Parser base class that holds parser functionality not specific
to the build manifest file format. This will allow it to be re-used for
other parsers later.
