Bake: a build system for C and C++ that configures projects in two lines of JSON

The problem Bake targets: C and C++ project setup that stays small

The README opens with a Dutch tax slogan and translates it as "We can't make it more fun, but we can make it easier". That is the project's stated position: building C and C++ will not become pleasant, so Bake aims to remove setup work instead. The README lists the specific pains it addresses, including minimal platform independent configuration ("as in 2 lines of JSON minimal"), referring to dependencies by logical names instead of OS dependent paths, automatically including headers from dependencies, and discovering, ordering and building projects in directories without additional config.

The target user is someone writing C or C++ who is tired of hand-written makefiles and per-platform path juggling. The README says Bake is used as the primary build system for Flecs, which is a concrete signal about the kind of codebase it was shaped around: a C library with dependencies and multiple configurations. It is not aimed at a polyglot monorepo. Everything in the README is about C and C++ compilation units, drivers for language-specific behaviour, and compiler invocation.

How Bake works: drivers, logical dependency names and a build environment

Bake is presented as zero-dependency and calls msvc, gcc, clang and emcc directly rather than generating another build system's files at build time. The repository layout supports this: there is a drivers/ directory, separate build-Linux/, build-Darwin/, build-Mingw/ and build-Windows/ directories, and a src/ tree. The manual has a chapter on writing drivers, which suggests compiler-specific behaviour is isolated there rather than scattered through the tool.

Dependencies are declared by logical name. The README's example config uses "use": ["foo.bar"], and the manual chapter on integrating non-bake projects implies that not every dependency has to be a bake project itself. Configuration is layered: a project has an id, a type such as application, and a value block, with language-specific settings under keys like lang.c. Environment variables that must be set during a build are stored in a bake.json file in the root of the bake environment, which defaults to $HOME/bake, and can be pushed into a shell with export `bake env`. Builds are recursive: the README claims it can "recursively build projects & their dependencies for the right config with a single command".

One design choice is worth flagging as a trade-off rather than a feature. Bake uses premake to generate its own makefiles, and the generated makefiles are committed to the repository. The README states that premake is not needed to use Bake, only to build Bake itself. That means the build files you see in build-Linux/ are generated artifacts checked into git, which is convenient for users and awkward for anyone who wants to audit exactly how a target is assembled.

Installing Bake and running a first project

Installation is a clone plus a setup script. On Linux and macOS the README gives these two commands, and notes that Bake installs a single script in /usr/local/bin that calls the binary in ~/bake, which may prompt for your password.

git clone https://github.com/SanderMertens/bake
bake/setup.sh

On Windows the README requires Visual Studio Build Tools or the full Visual Studio Community IDE, installed with the C++ CMake tools for Windows and Windows SDK components included in the Desktop development with C++ workload. The commands are a clone followed by setup from inside the directory.

git clone https://github.com/SanderMertens/bake
cd bake
setup

If you would rather not install the wrapper script, the README documents a local mode where the executable ends up in ~/bake and you add that directory to PATH yourself.

git clone https://github.com/SanderMertens/bake
cd bake
make -C build-$(uname) clean all
./bake setup --local

Once installed, the smallest real use is creating and running a project. The README gives exactly two commands for a new application called my_app.

bake new my_app
bake run my_app

A project configuration with a dependency and a system library looks like the README's example, which depends on foo.bar and links pthread for the C driver.

{
    "id": "my_app",
    "type": "application",
    "value": {
        "use": ["foo.bar"]
    },
    "lang.c": {
        "lib": ["pthread"]
    }
}

Day to day you run bake with no arguments to build, bake rebuild to start over, and bake clean to remove output. Adding --cfg release selects a build configuration, and adding --interactive to bake run rebuilds and restarts the application when a project file changes. To pull a project and its dependencies straight from git, the README documents bake clone with a repository URL.

Where Bake is the wrong tool, and what the documentation does not cover

The most concrete limitation is release cadence. The newest tagged release listed for the repository is 2.5.1, dated 2019-09-30, and the two before it are v2.5 from 2019-09-14 and v2.4 from 2019-08-25. The repository's last push is 2026-06-27, so work has continued on the default branch long after the last tag. Anyone who pins to a release number is pinning to something seven years old, and anyone who tracks master is tracking something that has not been cut into a release in that time. The README does not explain the gap or describe a release process.

Bake is also explicitly not a package manager. The README's FAQ answers the question "Is bake a package manager?" with "No.", then says it has package-management like features, and the text is truncated there. So the dependency resolution model is closer to a build-time convention than to a registry with version solving. If you need semver ranges across a public index, this is not that.

Several areas of the manual are named in the table of contents but not described in the README: template functions, project bundles, installing miscellaneous files, and the command line interface reference. The README does not document rollback of an upgrade, and it does not state what bake upgrade does if the network fetch fails. The repository also contains a .github/ directory with a workflow badge, but the README does not describe what that workflow verifies beyond the badge itself. Treat the manual as the source of truth and expect to read the source for anything it omits.

Bake compared with CMake and plain makefiles

The closest mainstream alternative is CMake, and the difference is in what each tool asks you to write. CMake projects describe targets, properties and find_package calls, and CMake generates a native build system for the platform. Bake instead calls the compiler directly, per the README's "zero-dependencies, calls msvc, gcc, clang and emcc compilers directly", and keeps project configuration to a small JSON file with an id, a type and a value block. A CMake user who wants a dependency usually needs a config package or a FetchContent declaration; a Bake user writes the dependency's logical name in a use array.

The second alternative is a hand-written makefile, which is what Bake is trying to spare you. The README's claim that Bake can "automatically discover, order and build projects in directories without additional config" is the part a makefile cannot do without recursive wildcard tricks. Against both alternatives, Bake gives up ecosystem breadth. CMake has years of third-party package configs and IDE integration; the README does not mention IDE support, presets or a package registry. If your dependency graph is mostly non-bake libraries, the manual's chapter on integrating non-bake projects is the thing to read before committing.

Licence, maintenance and upgrade cost

Bake is GPL-3.0. The README's FAQ addresses the obvious commercial question directly: it says that as long as you do not distribute Bake, either as source or binary, as part of your closed source deliverable, you can use Bake to build your projects, and compares this to using make, which is also GPL licensed. It also says customers can use Bake as long as they use the open source version and you do not ship Bake binaries or source with your product. That is the project's own reading of its licence, not legal advice, and the boundary it draws is distribution of Bake itself rather than distribution of what Bake builds.

On maintenance, the last push was on 2026-06-27, which is recent enough that the default branch is not abandoned, but the release history stops at 2019. Upgrades are handled by a single command, bake upgrade, which the README documents without describing rollback or version pinning. Because the tool bootstraps itself from a clone and installs a wrapper script, an upgrade replaces the binary in ~/bake rather than going through a system package manager, so there is no distro-level version to fall back to. Budget for reading the diff between your checkout and the upstream branch if you depend on specific behaviour.

Editorial conclusion

Bake fits developers who want a small JSON project file, logical dependency names and one command to clone, build and run a C or C++ project, and it is the practical choice if you already work inside the Flecs ecosystem. It is a poor fit if you need a current tagged release, since the newest is 2.5.1 from 2019-09-30, or if your build depends on CMake-style find_package integration. Verify the last push date, the contents of drivers/ and build-Linux/ for your platform, and the GPL-3.0 terms before you ship anything that bundles bake itself.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SanderMertens/bake on GitHub