A build system is the tool, plus the rules you write for it, that turns source code and its dependencies into finished software. Compiling a single file by hand is a one-off act; a build system captures the full recipe (which files to compile, in what order, against which libraries, into which outputs) so the same process can be run again and again with the same result. Make, Maven, Gradle, Bazel, and CMake are all build systems, each describing this recipe in its own language.
The core problem a build system solves is doing only the necessary work, correctly. Bazel’s documentation captures this when it says the tool “caches all previously done work and tracks changes to both file content and build commands,” letting it rebuild only what changed and “build in a highly parallel and incremental fashion.” Tracking what depends on what is central to any build system; it is the difference between recompiling everything every time and recompiling just what a change affects.
A build system also manages dependencies, the external libraries a project needs. Tools like Maven tie the build directly to an artifact repository, so the build can pull “dependencies for their own builds” from a central source rather than requiring developers to gather libraries by hand. By resolving named, versioned dependencies automatically, the build system makes the set of inputs explicit and repeatable.
Taken together, these jobs (sequencing compilation, avoiding redundant work, and resolving dependencies) are what separate a reproducible build from an ad hoc one. A reproducible build documented in a build system can be run by a new developer, a teammate, or an automated server and produce the same software, which is why build systems are foundational infrastructure for any nontrivial project.