Building with Ninja

Ninja is a build system originally developed for Google Chrome and designed towards low build times for complex projects. It was designed with three goals in-mind:

1. Ninja is supposed to be fast. Build processes are heavily parallelized where possibe.
2. Ninja files are meant to be computer-generated using higher order build systems such as CMake
3. Ninja itself is "painfully simple". There is "very little policy" in the build process and Ninja requires comparatively explicit build definitions.

This article explores the possibility for an alternative build system for Weissblatt based on Ninja to hopefully simplify and future-proof the engine's overall build process - especially in regards to multi-platform support and Windows builds.

Ninja compared to Make for building Weissblatt

Traditionally Weissblatt's engine used to be built using Make, the traditional UNIX build system for C/C++ programs. However, there are multiple reasons to consider migrating to a more modern build system:

1. The engine's Makefile has grown large, complex and hard to maintain over the years. Ninja is both brutally simple in it's architecture and doesn't assume human authorship from the get-go. As long as a good higher-level build system is used to generate Ninja files, maintenance of the build system should be trivial.
2. Although building with a working Makefile is simple on UNIX-like systems, Make's dependency on a UNIX-like environment makes cross-platform development difficult. Letting a higher-order build system generate system-appropriate Ninja files may both abstract the system's build tooling to developers and better tailor the build process towards each individual system.
3. To alleviate the problem described in 2), the Windows build system already relies on CMake separately of the Makefile for UNIX builds. Since CMake already supports generating Ninja files and is generally considered standard tooling in modern C/C++ development, a simple adaptation of Weissblatt's CMake toolchain could render a Ninja-based build toolchain easy to implement.

CMake in action - Generating Ninja files

Building with Ninja on Linux

Initially building on Linux using Ninja worked just fine. After configuring and generating a Ninja build tree using the CMake GUI, running Ninja from within that tree (per-default under build/ninja-release) seemed to have compiled a development version of the game without problem.

However, the general CMake infrastructure seemed complex with nested breakout files for toolchains and dependencies. How much of that is due to how the engine's build system is structured and how much is inherent to working with CMake is unclear.

The initial CMake system also required CMake's GUI tool to set the environment variables and generate the Ninja build tree. Ideally, a build process using a configuration file such as .env or .config could suit a more iterative development approach. This could be useful, as Ninja expects developers to keep regenerating Ninja files whenever the structure of the codebase changes - be it changed environment variables, added/deleted files or whatever else isn't directly concerned with compiling the code.

Building with Ninja on Windows

As Windows lacks built-in development tools. Thankfully both CMake and Ninja were easily installable through WinGet and were readily available as CLI tools right after. As getting GCC to run on Windows is an ordeal in itself, most Windows developers usually rely on either Clang or more commonly Microsoft's own MSVC compiler - part of Microsofts larger set of Visual Studio build tools.

Initially trying to configure the CMake project failed, as CMake could not find the system's C/C++ compiler: