nob.h: writing your C build recipe as a C program

What nob.h actually replaces

The README frames the project as "the next generation of the NoBuild idea": you should need nothing but a C compiler to build a C project. No make, no cmake, no shell, no cmd, no PowerShell. The build system is bootstrapped from the C compiler, and then that build system builds everything else. In practice this means the build recipe is a C program, compiled and run like any other, that shells out to the compiler through helpers the header provides. The audience is narrow and the README says so: people who are already writing C and are willing to write their build logic in C too. The author describes it as a research project and states he is not making claims about suitability for any project. He does say he uses nob across a variety of his own C projects and that it works well there.

How the library works: one header, a compiled recipe, subprocess calls

There is no daemon, no plugin system and no configuration format. The repository is a single header, nob.h, plus a nob.c that builds the project itself, and a how_to/ folder with examples. The header is included into your recipe program, which is ordinary C: you call helpers that spawn the compiler and other tools, and the recipe decides what runs and in what order. The README describes the model as being "more like writing shell scripts but in C", which is the honest description of the data flow. Your recipe is the orchestrator; nob.h is the standard library for it. The advantage the README claims is portability across Linux, macOS, Windows, FreeBSD and similar systems, achieved by reducing dependencies to just a C compiler. The second claimed advantage is language reuse: the build system can use the project's own code directly and the project can use the build system's code directly, because both are C. That is a real property of this design and also the reason it does not translate to other ecosystems.

Getting nob.h into a project and writing a first recipe

There is no package to install. The README says the only file you need is nob.h, and the instruction is to copy-paste it into your project and start using it. The how_to/ folder in the repository holds the examples to follow. The README does not document a build command for your own recipe, so the only step it actually gives is the file itself, which it links at raw.githubusercontent.com/tsoding/nob.h/refs/heads/main/nob.h. After that, your recipe is a C file, conventionally nob.c, that includes the header and drives the compiler. The repository's own nob.c is the working example of that file, and how_to/ holds smaller ones. What you should see, once your recipe compiles and runs, is your build output appearing with no makefile anywhere in the tree. The README does not document the individual helper functions, so read nob.h and the how_to/ examples before writing anything beyond the skeleton; the header is the specification.

Where nob.h stops being the right tool

The README contains the limitation itself: "It's likely Not Suitable for Your Project." If you use cmake with many modules to find dependencies, you probably do not want this. The author adds a personal view that in that case you have a bigger problem than the build system, which is an opinion, not a technical argument, and readers should treat it as one. The second stated disadvantage is the real cost: you need to be comfortable with C and implementing things yourself. There is no dependency resolver, no package registry integration, no generator for IDE project files, and no standard set of targets you inherit. Every project that adopts nob.h writes its own build logic, which means two nob.h projects share a header, not a build model. The README also notes it probably makes no sense outside C/C++ projects. A team that wants reproducible builds defined by a declarative file, reviewed by people who do not read C, will find this a poor fit regardless of how well it works for the author.

nob.h against make and cmake

Make and cmake are declarative: you describe targets, dependencies and rules, and the tool computes what to run. nob.h is imperative: your recipe is a program that decides what to run, and any dependency tracking beyond what the helpers give you is code you write. That difference explains both the portability claim and the adoption cost. A makefile needs make on the machine; a cmake build needs cmake and usually a generator. A nob.h build needs a C compiler, which is the one tool the README argues exists on essentially every platform. The trade is that make and cmake carry decades of conventions, generators and third-party modules, and nob.h carries none of them. If your build is simple and your team writes C all day, the imperative model is not much of a burden. If your build is the place where twenty external dependencies get located and configured, you are rewriting a job that cmake already does.

Maintenance, licence and the cost of copying a header

The last push to the repository was on 2026-09-21, so the project is being worked on. That matters more than usual here, because the update mechanism is copy-paste: you take nob.h into your tree and it becomes your file. There is no package manager to pull a new version, and the README does not document a rollback or upgrade procedure. Upgrading means diffing a new nob.h against the copy in your tree and resolving whatever changed, which is also the point at which you find out whether you depended on behaviour the header never promised. The repository lists a LICENSE file, but the licence is recorded as NOASSERTION, meaning the repository metadata does not resolve it to a recognised identifier. Read the LICENSE file in the repository before you copy the header into a product; this article cannot tell you what it permits. The how_to/ folder and the tests/ and tools/ directories are the places to look for how the author expects the header to be used and changed.

Editorial conclusion

Adopt nob.h if your project is already C or C++ and you are comfortable writing the build logic yourself: the whole setup is copying nob.h into the tree and writing a nob.c, and the how_to/ folder shows the shape of that. Do not adopt it if your build depends on cmake modules for dependency discovery, or if the build is not a C-family build at all; the README says the approach probably makes no sense outside C/C++ projects. Before committing, verify two things in your own tree: that the C compiler you target is the only tool your recipe needs, and that the rebuild logic you write actually tracks the headers your sources include, because nob.h supplies helpers and not a dependency graph.

Frequently asked questions

Official sources

1. Issues
2. README
3. tsoding/nob.h on GitHub