Build Systems Comparison

DRAFT

This is document is a draft. There is a lot of information we need to reconcile to create the feature matrix, so we are currently gathering feedback from the community.

We have only considered build systems that support Linux, macOS and Windows (not just MinGW). We have also only considered systems with a significant number of users.

Please check the timestamp of this post before making any decisions. Things can change!

	CMake	Meson	Bazel	Buck
Backing	Kitware	Meson	Google	Facebook
License	BSD-3-Clause	Apache-2.0	Apache-2.0	Apache-2.0
DSL	CMake Script	Custom (Pythonesque)	Python (Starlark variant)	Python (Starlark variant)
Runtime Dependency	None	Python	None	Python
Glob Support	Yes	No	Yes	Yes
Config Management	No	No	Yes	Yes
Sandboxed Execution	No	No	Yes	Experimental
Reproducible	No	Yes	Yes	Yes
Rust	Yes	Yes	Yes	Yes
Java	No	Yes	Yes	Yes
Python	No	No	Yes	Yes
JavaScript	No	No	Yes	Yes
Remote Caching	No	No	Yes	Yes
Remote Execution	No	No	Yes	No
Reusuable Macros	Yes	Yes	Yes	Yes
User Extensions	No	No	Yes	No
Header Tracking	No	No	Yes	Yes
Fast Android Deploy	No	No	Yes	Yes
Fast iOS Deploy	No	No	Yes	Yes

Features Explained

Config Management is where the build-system can support multiple build configurations into the same build folder without messing it up, and sharing build artefacts between configurations where possible. Conversely, systems like CMake require the developer to maintain a build folder for each configuration and be careful not to mix them.

Sandboxed Execution is where the build is run inside of a sealed environment so that it cannot access files and programs that are not explicitly declared as dependencies. This prevents dependencies from leaking into a project over time. It is also required for reproducible builds, remote artefact caching and remote build execution. This also enables greater parallelization of the build.

Backing is a bit of a loose concept, but roughly speaking it refers to who contributes significant code, owns the main source-control and manages releases. Remember that most build-systems are a community effort.

Remote Caching is where build artefacts (e.g. object files) are shared between projects and even across a network. This can dramatically improve build times, particularly as a team scales. SCCache is a more limited form of caching since it only works for C++.

Remote Execution is where the build is executed on a different machine to the user's, freeing up memory and CPU on the workstation. This is only possible with cross-compilation, well-defined toolchains and sandboxed build steps.

Reusuable Macros are libraries of functions written in the build system DSL that are reusable across projects.

User Extensions are where code written in the build-system's DSL can be used to define new target types and toolchains that can manipulate the build graph. This enables the user to add support for custom languages without modifying the build-system itself. This is subtly different to "Reusable Macros".

Header Tracking is a feature for C & C++. It gives you a warning whenever you include a header-file without explicitly declaring a dependency on the target it belongs to. You might find this desirable if you want to enforce module boundaries.

Fast iOS / Android Deploy is a feature where the build-system efficiently deploys a build of your program by leveraging the mobile toolchain. There is also an optimization opportunity here. For example, Buck's Exopackage will hot-reload a running Android app to accelerate development.

Notes

1. CMake glob support that does not require a re-configure to pick up new files was added at the end of 2018. However, the user must be careful to specify the CONFIGURE_DEPENDS flag, or it will not execute the glob during the build.