<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 2, 2015 at 4:05 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br><div class="gmail_quote"><span class="">On Fri Jan 02 2015 at 4:02:13 PM Rick Foos <<a href="mailto:rfoos@codeaurora.org" target="_blank">rfoos@codeaurora.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"><br></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Windows support for any non-MS packages can have gaps. For example, Ninja: Windows CMake 3.0.0 no longer ships Ninja. The Ninja from github doesn’t compile with the latest GCC or support msbuild particularly well.  Easy enough to workaround, stay with 2.8.8, but workarounds must be done for most anything on Windows.</span></p></div></blockquote><div><br></div></span><div>Can you elaborate on this?  I use CMake 3.0 with no problem.  Are you talking about how to get a ninja.exe binary on your system?  Ninja bootstraps itself, so you don't need CMake to compile ninja, and once you have a ninja.exe, it works just fine with CMake 3.0 </div></div>
</blockquote></div><br></div><div class="gmail_extra">There are also prebuilt ninja binaries available at <a href="https://github.com/martine/ninja/releases">https://github.com/martine/ninja/releases</a> for Windows, Mac OS X, and Linux.</div><div class="gmail_extra"><br>For why ninja is faster than other build systems, it depends if you look at full or incremental builds.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For full builds, build speed is mostly related to how many compile processes can be run in parallel. Many build systems add a "target" abstraction and then do scheduling at a target level, which means if a static library depends on another static library, all translation units in the first static library have to be compiled first and then linked into a static library before any compilation in the second library can start. Since compiling source files can't depend on a static library being present or not, this is an artificial limitation that needlessly serializes the build. Ninja only gets a description of the build graph, and cmake is smart enough to write build graph descriptions that do not make compiles of a downstream target depend on an upstream static library, for example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For incremental builds, ninja is fast because it does less: It only reads build manifests and header deps (which are written into a single deps log at build time, so it's only a single file to read), stats all input files, and does nothing else. Other systems often have an imperative (instead of a declarative) build description and run some scripts on every build unconditionally, they read and write ancillary files, and so on.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nico</div></div>