Beej's Guide to C: the source behind a free C book

A book, kept in a repository so translators can clone it

This is the source for Beej's Guide to C, and the README is very clear about who it is for. If you merely wish to read the guide, visit the website. The repository is here so the author has everything in one place and so translators can easily clone it.

That second reason is the interesting one. A book that is freely licensed and that the author wants translated into many languages needs its source somewhere a translator can fork, and Git is the natural answer. It also means the guide is a living document rather than a published artefact, and that the PDF and the website are build outputs rather than the original.

The guide itself is a C programming book. The project is written in C as far as the tooling goes, since the build scripts and the makefiles are what this repository contains, and the description names it Beej's Guide to C Programming source. The top level of the tree confirms the shape of a book project: an es/ directory, a source/ directory, a src/ directory with the actual content and its own Makefile, a translations/ directory, and a website/ directory.

The primary language of the repository is C, the default branch is main, the last push was on 2026-10-15, and there are no GitHub releases because the release artefact of this project is a book rather than a package. The licence is a custom one that GitHub cannot classify, with the licence file in the repository, and the pull request policy is worth reading because it explains the copyright reasoning.

The build needs a toolchain and a second repository

Building the PDF is not a one-liner, and the dependencies list is the first thing to read. You need Gnu make, with the note that XCode make works too, Python 3 or newer, Pandoc 2.7.3 or newer, XeLaTeX, which the README says can be found in TeX Live, and the Liberation fonts in sans, serif and mono.

On a Mac the install is a Homebrew sequence:

xcode-select --install                  # installs make
brew install python                     # installs Python3
brew install pandoc
brew install mactex                     # installs XeLaTeX
brew tap homebrew/cask-fonts
brew install font-liberation            # installs Liberation fonts

and the README notes you may have to add something to your path to find xelatex:

PATH=$PATH:/usr/local/texlive/2021/bin/universal-darwin

Then there is the dependency that catches people out, because it is not in this repository. The build depends on an external repository, the Beej's Guide Build System for Pandoc, and you are expected to clone it as a sibling to this one:

mystuff-->bggit
      \-->bgbspd

The Makefiles here look for the build system at that sibling location, and you can point it elsewhere with an environment variable:

export BGBSPD_BUILD_DIR=/some/path/to/bgbspd

So the build is two repositories side by side, and the top-level Makefile is four meaningful lines. It sets the package name to bgc, defaults the build system directory to a sibling path, and includes the shared main.make from there. Everything else about how the book is assembled lives in the other repository, which is a deliberate split for someone maintaining several guides at once.

Three make targets and no step three

The build itself is short, and the README is unusually pleased about it.

You type make from the top-level directory. If you have Gnu Make it should work fine, other makes might work as well, and the README suggests Windows users might want to check out Cygwin. Then you type make stage to copy all the build products and the website into the stage directory. And then it says there is no step three.

You can also change into the src directory and run make there, which is the path to building only the content rather than the whole site and the staged output. For cleaning there are two targets, make clean and make pristine, where pristine cleans back to the original state.

The font question is answered in the src Makefile, which the README points to for examples of embedding your own fonts in the PDFs. That is worth noting if you are translating or reskinning the book, because the Liberation fonts are the default typeface and the makefile shows how to change them.

For a release there is an upload target in the root Makefile, which demonstrates the build steps for a complete release. You have to change the UPLOADDIR macro in the top-level Makefile to point at your host if you want to use it, and the README notes you are free to upload whatever versions you desire individually. So the publishing path is a make target, not a release pipeline, which fits a project whose artefacts are books rather than packages.

Translations, and why pull requests are capped

The pull request policy is one line and it explains itself: please keep these on the scale of typo and bug fixes, that way the author does not have to consider any copyright issues when merging changes.

That is a real constraint and a sensible one. A book is a copyrighted work, and accepting large contributions makes the ownership of the result harder to reason about. Restricting the pull requests to corrections means the substantive text stays attributable to the author, and the translation workflow carries the effort instead.

The translations/ directory at the top of the tree is the mechanism, and it connects back to the stated reason for keeping the source in a repository. A translator clones the repository, works in their language, and produces a version of the book, and the git history keeps the two in step. The same git infrastructure that lets the author revise the guide lets a translator track the revisions.

The TODO list at the end of the README is a short window into the state of the work. It names four items: projects, more information on reserved identifiers, digraphs and trigraphs, and C23. The first is a subject area to add, the second and third are language details to expand, and the fourth is a version of the language to cover. The digraphs and trigraphs item is the kind of historical C detail that a book about the language at this level either covers properly or skips, and the fact that it is on the list says it is still being written.

Where this repository is the wrong thing to depend on

The first wrong case is expecting a tool or a library. The only code in this repository is the build system and the content, and the deliverable is a document. If you are looking for a C library, a header or a tool, there is nothing here to install.

The second is a build environment you do not want to assemble. Pandoc, XeLaTeX, a TeX Live installation, the Liberation fonts, Python and a sibling clone of another repository is a lot of machinery to produce a PDF you can read on the website instead. The README points you at the website for reading, and for most readers that is the right route.

The third is a team that needs a maintained document pipeline. There are no GitHub releases, the build depends on an external repository that has to be placed correctly, and the release path is a make target with a hardcoded directory macro to edit. That is fine for one author publishing books, and it is a friction point for anyone who wants to automate PDF generation across a fleet of documentation projects.

The fourth is a project that needs the content under a different licence. The licence is a custom one that GitHub cannot classify, so if your organisation checks licences automatically, this will not resolve without a human reading the file.

The alternative worth weighing is the website itself, which is free, needs no toolchain, and is updated by the author. The repository earns its place for translators, for people who want the text offline, and for anyone who wants to check the history of how a particular explanation was revised, and for everything else the website is the better deal.

Editorial conclusion

Adopt this repository if you want to read a thorough C book offline, or if you want to translate it, since the author keeps the source in a repository specifically so translators can clone it and pull requests are limited to typo and bug fixes. Keep away if you were expecting a C library or a tool, because this is documentation source and the only code is a Makefile. Before you build the PDF, install the full toolchain, since Pandoc, XeLaTeX, the Liberation fonts and Python are all required, and note the build depends on a separate repository that has to sit next to this one, with the last push on 2026-10-15 and no tagged releases.

Frequently asked questions

Official sources

1. beejjorgensen/bgc on GitHub
2. Issues
3. README