cmkr lets you describe a C++ project in TOML

A TOML file in front of a generated CMakeLists.txt

cmkr, pronounced cmaker, is a modern build system based on CMake and TOML, and its mechanism is a generator rather than a replacement. It parses cmake.toml files and generates a modern, idiomatic CMakeLists.txt for you.

The minimal example in the README is the whole idea:

[project]
name = "cmkr_for_beginners"

[target.hello_world]
type = "executable"
sources = ["src/main.cpp"]

That is the project name, the target type, and the source list, in a format that reads like configuration rather than like a script. What comes out the other side is a CMakeLists.txt that any CMake user can read, and, crucially, a build that any CMake user can run without knowing that cmkr exists.

That last point is what separates this from the many projects that try to replace CMake. Nothing about the resulting build changes. Your CI still runs cmake, your IDE still understands the CMake project, and a colleague who has never heard of TOML can open the generated file and understand it, because it is a normal CMakeLists.txt.

The topics attached to the repository reflect the intent as well: beginner-friendly, modern-cmake, modern-cpp and toml. The template repository is literally named cmkr_for_beginners.

Bootstrapping takes two commands

Getting started is a curl of the bootstrap script and a run of it, from your project directory:

curl https://raw.githubusercontent.com/build-cpp/cmkr/main/cmake/cmkr.cmake -o cmkr.cmake
cmake -P cmkr.cmake

The first command downloads cmkr.cmake and the second runs it as a CMake script with the -P flag, which is the mode where CMake executes a script rather than configuring a project. The script is what builds the cmkr executable for your platform.

The design constraint that follows from this is stated plainly: cmkr can bootstrap itself and you only need CMake and a C++ compiler to use it. No package manager, no Python, no separate installation step, and no version of cmkr to install before you can install cmkr.

That is a deliberate choice for a tool whose users are often beginners. The cost is that the bootstrap script is a downloaded file that you then run, which is a supply chain consideration that a package manager would normally handle for you, and

After that the workflow is plain CMake

Once bootstrapped, cmkr does not introduce extra steps into the workflow, and the README says so directly. After modifying cmake.toml you simply build or configure your CMake project, and cmkr will automatically regenerate the CMakeLists.txt when necessary.

The commands are the ordinary ones:

cmake -B build
cmake --build build

The regeneration is the part that matters. A generator that only ran when you remembered to run it would drift out of sync with the TOML file, so the generated CMakeLists.txt is refreshed as part of the normal configure step, and the source of truth stays cmake.toml.

The note about source control is explicit: the cmake.toml project file, the generated CMakeLists.txt and the cmkr.cmake bootstrapping script are all intended to be added to source control. Committing the generated file is unusual for a build system, and it has a clear purpose. It means that a clean checkout can be configured and built by anyone with CMake, including a CI runner that knows nothing about cmkr, and that a build failure is a failure of the committed file rather than of one person's local generator.

For CI, the README notes that the bootstrapping process is skipped, so there is no additional overhead in your pipelines. The generator runs when the configuration changes, and the pipeline just configures and builds.

A command line utility that mostly wraps cmake

Optionally you can put a cmkr release in your PATH and use it as a utility from the command line, and the usage text is short enough to take in at a glance:

Usage: cmkr [arguments]
arguments:
    init    [executable|library|shared|static|interface] Create a project.
    gen                                                  Generates CMakeLists.txt file.
    build   <extra cmake args>                           Run cmake and build.
    install                                              Run cmake --install.
    clean                                                Clean the build directory.
    help                                                 Show help.
    version                                              Current cmkr version.

The subcommands split into two groups. init, gen and version are cmkr's own work, and the init subcommand takes a target type, with executable, library, shared, static and interface as the choices, which is a friendlier entry point than writing a target block by hand. build, install and clean are thin wrappers over the equivalent cmake commands, with build accepting extra cmake arguments.

So the command line tool is a convenience layer, and its main value is init, which turns a blank directory into a configured project in one step. The wrappers are the sort of thing that saves a few keystrokes and also removes the ability to see what is really being run, which is a trade most users will not think about twice.

The template route skips bootstrapping entirely

The second way in is the template repository, cmkr_for_beginners, and the README gives two options for it. You can open it in Gitpod, or clone it and run the same two CMake commands:

cmake -B build
cmake --build build

The fact that the template needs no bootstrap step is the point of it. Since all three files are meant to be committed, a clone of the template is immediately buildable with nothing but CMake and a compiler.

That also means the template teaches by example. The structure of a project file, the target blocks and the way the generated CMakeLists.txt relates to the TOML are all visible in a repository you can read before you write any of it, which is a better way to learn the schema than a reference page.

The README points further in three directions for more examples: the cmkr topic on GitHub, the build-cpp organisation, and the tests directory of the cmkr repository itself, which is the closest thing to a gallery of configurations.

Where cmkr is the wrong tool

The first case is a project whose CMakeLists.txt uses features the TOML schema cannot express. cmkr generates a file, and a generator can only generate what its schema describes, so a project with unusual custom commands, complex generator expressions or a hand-tuned structure either has to be expressed in the schema or has to give up on cmkr. The schema documentation lives at build-cpp.github.io/cmkr/cmake-toml, and that page is the place to check before committing.

The second case is a team that will not accept a generated file in the repository. Some projects treat CMakeLists.txt as hand-written source, reviewed and edited by people who do not want a generator rewriting it. For such a project, cmkr is actively in the way, because the generated file is expected to be committed and regenerated.

The third is a project that has already solved this problem. A large C++ codebase with an established, well organised CMakeLists.txt gains little from expressing the same structure in TOML, and the migration is not free, since the schema is not a one to one translation of CMake.

There is also a smaller objection worth naming. The generator adds a step to the moment when the build definition changes, and it adds a tool that has to be kept in step with the CMake version you use. The README's answer is that the regeneration happens automatically as part of configuring, which is true, but the underlying dependency on cmkr matching your CMake is a real one.

MIT terms, a C++ implementation, and the release cadence

The licence is MIT, with the LICENSE file at the repository root, and the project page is cmkr.build.

The tool itself is written in C++, which is the natural choice for a tool that has to be built before you have a project to build with. The repository layout shows a normal C++ project with src/, include/, a cmake/ directory that holds the bootstrap script, tests/, third_party/ and docs/, and both a cmake.toml and a CMakeLists.txt at the root, which is the dogfooding case: cmkr's own build is described in the format it produces.

The credits list the third party code it builds on, which is a good way to read the implementation choices: gulrak/filesystem, Tessil/ordered-map, ToruNiina/toml11 for the TOML parsing, and mpark/variant. A variant type in the parser is a strong hint about how the tool models a schema with optional fields, which is the part of a TOML to CMake mapping that has no obvious answer.

The release history shows a project that ships when it has something to ship. The recent tags are v0.2.47 on 2026-08-22, v0.2.46 on 2026-02-01 and v0.2.45 on 2025-08-26, so the version numbers climb steadily while the release dates are irregular. The repository is not archived and the last push was on 2026-08-22, the same day as the newest release.

Editorial conclusion

cmkr fits a team that wants a declarative, reviewable project definition and finds CMakeLists.txt syntax hard to read, especially beginners or a team where the build file is edited rarely enough that its verbosity costs more than it earns. It does not fit a project that needs CMake features the TOML schema cannot express, and it does not fit a team unwilling to commit a generated file. Before adopting it, read the cmake.toml documentation to see how much of your existing CMakeLists.txt the schema can hold, and commit the generated CMakeLists.txt as the README instructs, since a build that only works on the machine that generated it is not a build.

Frequently asked questions

Official sources

1. build-cpp/cmkr on GitHub
2. License: MIT
3. Project website
4. README
5. Releases