See comment in #1899. Also adds two tests to output_test.py which check
this behaviour by relying on Python's suprocess.check_output not piping
stderr.
Since commit 86f606fe (Remove path component limit from input of
CanonicalizePath in windows, 2017-08-30, v1.8.0^2~2^2), the only failure
case in the `CanonicalizePath` implementation is the "empty path" error.
All call sites have been updated to ensure `CanonicalizePath` is never
called with an empty path. Remove error handling from the signature to
simplify call sites.
Update call sites that might have empty paths to explicitly check for
them before calling CanonicalizePath. Note that the depfile parser
ensures all parsed outs and deps are non-empty.
Just because `unistd.h` exists does not mean it has the APIs that are
needed. This occurs when cross-compiling using Fedora's packaged MinGW
toolchain.
Removes the selection of a fixed Xcode version added in 242b7dd which assured Xcode version 12.2 was used when the default was still 12.1. The GitHub default is now 12.4 and newer versions will be made the default a few weeks after the stable release. This commit ensures an up to date Xcode version is used in the CI.
When a path loaded from a depfile does not have a node, we create a new
node with a phony edge producing it. If we later load a dyndep file
that specifies the same node as an output of a known edge, we previously
failed with a "multiple rules generate ..." error. Instead, since the
conflicting edge was internally generated, replace the node's input edge
with the now-known real edge that produces it.
These expose some behavior related to implicit deps unknown to ninja and
timestamps with generating them as part of a rule.
See discussions in #1932 and #1933.
This reverts commit 67fbbeeec9.
There were a few missing test cases exposed by CMake's test suite that
need slight adjustments. Better to revert the original attempt, add the
test cases, and then re-land the change with the fixes.
Fixes#1932
If an edge's output files' mtimes are compared to the most recent
input's mtime, edges might be calculated as clean even if they are
actually dirty. While an edge's command is running its rule to produce
its outputs and an input to the edge is updated before the outputs are
written to disk, then subsequent runs will think that the outputs are
newer than the inputs, even though the inputs have actually been updated
and may be different than what were used to produce those outputs.
Ninja will now restat all inputs just prior to running an edge's command
and remember the most recent input mtime. When the command completes,
it will stat any discovered dependencies from dep files (if necessary),
recalculate the most recent input mtime, and log it to the build log
file. On subsequent runs, ninja will use this value to compare to the
edge's most recent input's mtime to determine whether the outputs are
dirty.
This extends the methodology used by restat rules to work in all cases.
Restat rules are still unique in that they will clean the edge's output
nodes recursively if the edge's command did not change the output, but
in all cases, the mtime recorded in the log file is now the most recent
input mtime. See the new tests for more clarification.
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
In my tests, nested maps outperform a large map of pairs by 10-20% on a
sample Chromium missingdeps run, and are arguably simpler due to fewer
ifdefs needed.
The tool looks for targets that depend on a generated file, but do not
properly specify a dependency on the generator. It needs to be run after
a successful build, and will list all potential flakes that may have
broken the build, but didn't due to accidental build step ordering.
The search relies on the correctness of depfile and generator output
information, but these are usually easier to get right than dependencies.
The errors found can usually be verified as actual build flakes by trying
to build the listed problematic files alone in a clean build directory.
Such builds usually fail with a compile job lacking a generated file.
There is some overlap between this tool and 'gn check', but not everyone
uses gn, not everyone using gn uses gn check, and most importantly, gn
check is more about modularity, and less about actual build-time deps
without flakes.
The tool needs to be run after a build completes and depfile data is
collected. It may take several seconds to process, up to a dozen or
two on a large, chromium-sized build.
Revise the logic from commit 2d7f7e55 (Delete read-only files on
Windows, too, 2020-12-07) to check if `GetFileAttributes` or
`DeleteFile` failed due either variant of the file/path-not-found error.
Issue: #1886
