Bake: A Build System That Discovers Projects Instead of Being Told About Them
Bake, A build system for building, testing and running C & C++ projects
At a glance
- What is it?
- Bake is a C and C++ build tool from SanderMertens that ships its own compiler drivers, test framework, and project scaffolding. Its pitch is minimal JSON configuration and automatic project discovery. The trade-offs are a GPL-3.0 licence and a release cadence that stalled in 2019.
- Who is it for?
- Adopt Bake if you maintain a directory tree of C or C++ projects that share dependencies and you want one command to build, run, and test them without hand-written build scripts. Do not adopt it if your build needs IDE integration, a large third-party ecosystem of find-modules, or a tool with recent tagged releases; the newest release listed is 2.5.1 from September 2019.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 81 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Bake targets: build scripts that describe the machine, not the project
Most C and C++ build tools ask you to describe your project in terms of the machine it will run on. You list source directories, include paths, library search paths, and compiler flags, and the tool assumes those paths are stable. Bake inverts that. The README states that you "refer to dependencies by logical names, no OS/environment dependent paths," and that headers from dependencies are included automatically. The unit of configuration is a project with an id and a type, not a directory of files with flags attached.
This matters most when you have several projects that depend on each other. The README claims Bake can "automatically discover, order and build projects in directories without additional config" and "recursively build projects & their dependencies for the right config with a single command." If that holds for your layout, the payoff is that adding a new library to a tree requires no edit to a central build file. It is aimed at people who maintain such trees: library authors, game developers (the repository lists gamedev and indiedev as topics), and anyone who has written the same CMakeLists.txt boilerplate for the fifth time. The README is explicit that Bake is used as the primary build system for Flecs, so the author's own project is the reference case.
How Bake works: a driver per compiler, a JSON project file, and a bake environment
Bake does not generate Ninja or Make files for your project. The README says it is "zero-dependencies" and "calls msvc, gcc, clang and emcc compilers directly." The manual has a section on "Writing drivers," which implies the compiler invocation is abstracted behind a driver layer that Bake selects per platform and compiler. That is a different architecture from generators like CMake or Premake, which emit files for another tool to consume.
The project file is JSON. A minimal project is described by the README as "2 lines of JSON minimal," and the example given is an object with id, type, and value keys. Dependencies live under value.use as an array of logical names such as "foo.bar". Language-specific settings sit in a namespaced block: the example uses "lang.c" with a "lib" array containing "pthread". So the schema is extensible by language and by key, and the driver reads the keys it understands.
There is also a persistent Bake environment. Environment variables exported with bake export are stored in bake.json at the root of that environment, which defaults to $HOME/bake. The command export `bake env` prints the variables so a shell can import them. This is how Bake handles things like PATH or LD_LIBRARY_PATH additions without you editing shell profiles by hand.
The repository layout reinforces the driver model: Bake itself is built with generated makefiles. The FAQ notes that a premake file exists in the repository but that "the generated makefiles are included in the bake repository, so you won't need premake to use bake." That is a bootstrapping concession, not a dependency you inherit.
Installing and running: the commands the README actually gives
Installation on Linux and macOS is a clone followed by a script. The README shows:
git clone https://github.com/SanderMertens/bake bake/setup.sh
On Windows the sequence is a clone, a cd into the repository, and running setup, with a prerequisite of Visual Studio Build Tools or the full Visual Studio Community IDE including the C++ CMake tools for Windows and Windows SDK components. On Linux and macOS, the README states that setup installs a single script in /usr/local/bin that calls the bake binary in ~/bake, and that this "may prompt for your password during installation."
If you do not want that script, the README gives a local-mode path:
git clone https://github.com/SanderMertens/bake cd bake make -C build-$(uname) clean all ./bake setup --local
After that the binary lives in ~/bake and you add that directory to PATH yourself.
Day-to-day use is short. bake new my_app scaffolds a project; bake run my_app builds and runs it; adding --interactive rebuilds and restarts the application when a project file changes. Bare bake builds, bake rebuild and bake clean do what their names say, and bake --cfg release selects a configuration. To pull a project and its dependencies from git, the README gives bake clone https://github.com/SanderMertens/example. Upgrading is bake upgrade.
One detail worth noting for anyone scripting this: the README says bake --help lists all options and commands, so the CLI surface is discoverable without the manual.
Where Bake is the wrong tool
Bake is not a package manager, and the README says so directly in the FAQ: "Is bake a package manager? No. Bake has package-management like features." If you need version resolution across a public registry, transitive constraint solving, or lockfiles that pin exact revisions for reproducible builds, that is outside what the README describes. Dependencies are referenced by logical name and resolved through the Bake environment and bundles, which is a different guarantee.
The release history is the other hard constraint. The most recent release listed is 2.5.1 from 2019-09-30. The repository is not archived and the last push is dated 2026-06-27, so development activity continues on master, but anyone who pins to tagged releases is working with a version that is years old. That combination (active branch, stale tags) means you should decide deliberately whether to track master or a tag, and the README does not tell you which is supported.
Compiler coverage is stated narrowly. The README lists gcc 7, 8, 9, and 10; clang 8, 9, and 10; and msvc. Newer major versions are not mentioned. If your toolchain is outside that list, the README gives you no assurance, and since Bake invokes compilers directly rather than emitting a portable build description, there is no fallback path where another tool picks up the slack.
Finally, the direct-invocation model means you do not get the inspection layer that generator-based tools provide. There is no build.ninja or compile_commands.json mentioned in the material to hand to clangd, and no described integration with IDEs. Teams that rely on those artifacts should treat this as a gap until they confirm otherwise.
How Bake differs from CMake and Meson
CMake and Meson are generators. You write a description of targets, and the tool produces files for Make, Ninja, or an IDE to execute. Bake skips that stage: per the README it calls the compilers directly, which is why it can claim zero dependencies. The practical difference is where your build logic lives. With a generator, the intermediate files are inspectable and portable to other build runners. With Bake, the driver is the build runner, and the only description is your JSON project file plus whatever the driver infers.
The configuration surface differs too. A CMakeLists.txt is a program in a scripting language; it can compute, branch, and query the system. Bake's project file as shown in the README is declarative JSON with id, type, value.use, and language blocks. The README's claim that discovery and ordering happen "without additional config" is the payoff of that constraint, and also its limit: anything the driver cannot infer has to be expressible in the schema.
Bake also bundles things that CMake leaves to other tools. The README lists a test framework, address sanitizer support, single-header generation from any project, and a strict compilation mode intended to make projects "warning free on all compilers/compiler versions." CMake has CTest, and sanitizers are usually wired up by hand or through a helper script. Bake puts those in the tool. Whether that is convenient or confining depends on how much of your workflow you want owned by one binary.
Licence and maintenance cost
Bake is GPL-3.0. The README's FAQ addresses the obvious question for commercial users: you can use Bake for commercial projects as long as you do not distribute Bake, as source or binary, as part of your closed-source deliverable. The README compares this to using make, which is also GPL licensed. It also states that your customers may use Bake provided 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 a legal opinion, and if your distribution model is unusual you should get your own advice rather than relying on an FAQ entry.
Maintenance cost splits into two parts. Upgrading the tool is one command, bake upgrade, so staying current with master is cheap mechanically. The expensive part is the risk profile: with the newest tagged release dated 2019, you are either tracking an untagged branch or accepting a release that predates several compiler generations. Neither is free. Tracking master means your build tool changes underneath you between builds; pinning means you are on your own for anything fixed since.
There is also a bootstrapping wrinkle to plan for. The repository contains a premake file used to generate Bake's own makefiles, and those generated makefiles are committed. If you ever need to rebuild Bake from scratch rather than using setup.sh or setup, you are relying on makefiles that were checked in rather than regenerated, which is a maintenance detail the README acknowledges but does not elaborate on.
What to check before you commit to Bake
The first thing to verify is discovery. The README promises that Bake finds, orders, and builds projects in directories without extra configuration, but it does not specify the layout it expects. The manual has a "Project layout" section, so the rules exist; read them and compare against your tree before assuming your existing structure qualifies. A build system that discovers projects is only convenient if it discovers yours.
The second is the dependency story. Logical names are pleasant until you need to know what a name resolves to. The README describes bundles for managing projects and their git repositories, and bake clone for pulling a project with its dependencies, but it does not describe how a logical name maps to a specific revision. If reproducible builds matter to you, that mapping is the thing to pin down.
The third is toolchain fit. Confirm your gcc, clang, or msvc version is inside the listed range, and if you target the web, note that emscripten support is built in via emcc, which is one of the few capabilities here that generator-based tools typically require add-on modules for. Then run bake new on a throwaway project, build it, and check whether the generated layout and the resulting compile commands are something your team can live with. That is a ten-minute experiment and it will tell you more than the feature list does.
Editorial conclusion
Adopt Bake if you maintain a directory tree of C or C++ projects that share dependencies and you want one command to build, run, and test them without hand-written build scripts. Do not adopt it if your build needs IDE integration, a large third-party ecosystem of find-modules, or a tool with recent tagged releases; the newest release listed is 2.5.1 from September 2019. Before committing, verify that your compilers are covered (the README lists gcc 7 through 10, clang 8 through 10, and msvc), that your team accepts GPL-3.0 tooling, and that bake setup --local works on your machines without the /usr/local/bin script.
Community notes