Whatever language or framework you use, it has a “Getting Started” page. This always provides the quickest path to get started, and includes the setup for any compilers or other tools are needed to run the code.
Quickstart tools are generally:
- tied to a specific language, sometimes at a particular version
- integrated with a single toolchain for simplicity
- designed for small- to medium-scale applications
Many projects start small, and continue using these tools even as the codebase and team grow, and the software is written in multiple languages (sometimes called “full-stack”). As you run into limitations, the "band-aid" approach is to script around the tools, for example with a Bash program that:
- encodes some common commands needed to get your machine in the "right state" for the tools to work
- builds some libraries, then afterwards an application
- checks what files were changed to reduce how many test cases to run
- much more!
This ad-hoc solution only buys a limited amount of time.
In contrast, a general purpose build system is meant to solve these limitations for typical developer workflows, while scaling to really large codebases in many languages.
There are a few options:
- Bazel: you'll learn about it in this course!
- Make: very mature, and shares some properties with Bazel. However it doesn't enforce layering between declaring the structure of the source code and imperative code listing the commands to run, so it's brittle.
- Buck: a Bazel clone developed at Facebook. The new Buck2 rewrite seems very promising and Aspect plans to track development over 2025-2026. We may support it in the future.
- Pants: a Bazel clone developed at Twitter, but now seemingly End-of-Life as the commercial backer folded (toolchain.com)
- MSBuild: not adopted much outside Visual Studio.
- Gradle Build Tool: typically used in Java/Kotlin projects with Develocity (previously Gradle Enterprise)
- Nx: typically used in frontend monorepo projects, has some early support for more languages.
Read More in this Research paper: Build Systems a la carte
You may think of a CI tool like Jenkins as a build system, but in fact these are separate layers. The CI tool is responsible for scheduling when to kick off a build, but they have limited ability to understand the orchestration of dozens of compilers, code generators, testing tools, and more.
