| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Build ninja with C++11
In order to allow future use of std::chrono to make the stats code
portable it is desirable to compile with C++11. Doing so also allows use
of std::unordered_map, and reduces the number of #ifdefs in the ninja
source code.
Switching to C++11 requires modifying both CMakeLists.txt and
configure.py, for MSVC and for other build systems. For MSVC the
required change is adding /Zc:__cplusplus to tell the compiler to
give a more accurate value for the __cplusplus macro. For other
platforms the change is to add -std=c++11 or the CMake equivalent.
This change makes some progress towards resolving issue #2004.
* Delete code and instructions
C++11 guarantees that string::data() gives null-terminated pointers, so
explicitly adding a null terminator is no longer needed.
The Google C++ Style Guide already recommends avoiding unnecessary use
of C++14 and C++17 so repeating this in CONTRIBUTING.md is not critical.
These changes both came from PR-review suggestions.
* Only set cxx_std_11 if standard is 98
* Return to unconditional target_compile_features use
After much discussion it sounds like using target_compile_features
unconditionally is best.
|
| |
|
|
|
|
| |
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.
|
