[lldb-dev] MSBuild vs. Ninja build-timings on Windows

[Nico Weber]

On Fri, Jan 2, 2015 at 4:05 PM, Zachary Turner <zturner at google.com> wrote:

>
>
> On Fri Jan 02 2015 at 4:02:13 PM Rick Foos <rfoos at codeaurora.org> wrote:
>
>>
>> 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.
>>
>
> 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
>

There are also prebuilt ninja binaries available at
https://github.com/martine/ninja/releases for Windows, Mac OS X, and Linux.

For why ninja is faster than other build systems, it depends if you look at
full or incremental builds.

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.

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.

Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150103/af5b5e3f/attachment.html>