Widelands ships a sanitizer by default and a file of known leaks

A twenty-five-year-old inspiration and a build that starts under a sanitizer

The project describes itself in two sentences. It is a free, open source real-time strategy game with singleplayer campaigns and a multiplayer mode, and it was inspired by a commercial title from the mid-nineties, with the page claiming significantly more variety and depth.

The claim about depth is the project's own, and it is the only comparison the page makes. It does not enumerate what was added, which is the sort of detail a page like this could easily have provided and does not.

On licensing there are two layers. The code is GPL version 2 or later, and some assets are released under a range of Creative Commons licences, with the page pointing you at the folders in question rather than listing them. For a game whose content is a large fraction of its bulk, that split is worth knowing about before you redistribute anything you build from it.

The build story is the opposite: the dependencies are listed precisely and the compiler requirements are stated as floors rather than as recommendations, for Linux, for Windows under two different toolchains, and for macOS with a named compiler version.

The first thing you learn from the option table, though, is that a debug build of this game runs under a memory sanitizer unless you turn it off.

Switching the sanitizer off is a one-way door

The address sanitizer option is listed with three defaults rather than one. It is on for debug builds and off for release builds, and its function column carries the sentence that makes this option unusual: switching it off only works once, and you will have to clear the build directory if you want to switch it off again in a later build.

That is a build-system fact rather than a policy, and it comes from where the flag is read. It is recorded because it is the kind of thing that costs an afternoon, and the page chose to write it down rather than leave it to be discovered.

Next to it sits a thread sanitizer option, off by default and explicitly mutually exclusive with the address one. Two sanitizers cannot run at once, and the page says so in the row rather than leaving you to find out.

The repository supports the practice. At the root there is a file of known third-party leaks for the address sanitizer, and a separate suppression file for the memory checker. A project that turns a sanitizer on by default in its own debug builds is a project that expects to hit leaks it did not write, and both of those files are the evidence.

Two more build targets are worth noting. One generates documentation, and it is only available in debug builds, with a comment that this is easily changed if necessary. The other installs into a system directory that defaults to a local prefix and needs root privileges.

A Python floor of 1.5.2 and a version option that still knows Bazaar

The dependency list is eleven items and reads like a build from the last decade, because it is.

Four are the simple direct media library: the base library at 2.0 or newer, its image, mixer and font extensions. Two are compression and internationalisation libraries. One is PNG. One is an asynchronous networking library. One is the OpenGL extension loader, with an alternative bindings library offered as a substitute. And one is Python, with a minimum of 1.5.2.

That version number is the one that stops you. A floor of 1.5.2 refers to an interpreter from the start of the previous century, which tells you the dependency is named in the build system and not actually exercised at that version. It is the kind of figure that is never updated because nothing enforces it.

The other old reference is in the options table, where the version can be autodetected from the two version control systems named beside it. One of those is the primary system; the other is a distributed version control system that has been effectively abandoned for more than a decade, and its continued presence in a build option means the detection logic has a branch nobody exercises.

Between them, the two figures are a good summary of a mature project: the dependency list is maintained conservatively, and the corners of it have not been revisited.

Two build paths, and the manual one leaves your binary in the build tree

There is a convenience script and there is manual CMake, and the page gives both.

The convenience script has four documented invocations and nothing else to learn: no flags for a full debug build, two flags for a release build, a different pair for a release build with debugging symbols left in, and a flag that lists the options. The dependency installer beside it also takes either no argument, in which case it detects your distribution, or a distribution name.

The manual path is where the friction shows. You make a build directory, change into it, run the generator and the build, and then, to actually run the game, you change back up a level and move the executable out of the build directory before launching it.

That last step is not explained anywhere on the page. It is presented as part of the sequence, between two blocks that both end with running the program, which means a reader following the instructions literally will produce a binary sitting in a subdirectory of the build tree and then copy it out before running it.

For the Ninja route the same three commands appear with the generator switched and the build command switched, plus a note that depending on how Ninja is installed the last command may have a different name. That is a small portability hedge, and it is the only place the page admits that the toolchain around it may vary.

The option table documents its own sharp edges

Most projects list build options as a reference. This one annotates them.

The build type takes three values and defaults to debug, which tells you what the project considers the primary development configuration. Link-time optimisation is autodetected rather than defaulted, so it turns itself on where the toolchain supports it. Whether the standard filesystem library needs an extra library linked is also autodetected, from the compiler version, which is the correct way to handle it and the sort of thing that usually gets hard-coded.

Then the platform-specific ones, each with its constraint stated: following the XDG base directory specification is on and only available on Linux; using the alternative OpenGL bindings library instead of the loader is off; linking the loader statically is off; producing a statically linked executable on Windows is off; and using bundled archive sources instead of looking for an installed library is off.

The install pair is worth a second look. The install prefix takes a directory and defaults to a local prefix, which the targets section notes means a system location requiring root unless you change it, and the subdirectory for executables defaults to a folder named for games inside that prefix. So the default install layout is a game-shaped path under the prefix, and the release-target directory has to be overridden for anything that is not a game.

A single configuration flag, taken from the same table, switches the build type directly:

cmake -DCMAKE_BUILD_TYPE=Release ..

A bot mirrors the repository across two forges and formats it there

The contributing section describes an arrangement that is unusual enough to be worth reading twice.

The master branch, and all issues and pull requests, are mirrored bidirectionally between the project's developer environments on two different forges, and a bot does it. The same bot formats the code in three languages across all the mirrored branches.

So there is no canonical host. An issue opened on one forge appears on the other, a branch pushed to one appears on the other, and formatting is applied automatically wherever the branch lands. The practical effect for a contributor is that the merge path is not obvious: you pick a forge, and a machine moves the work.

The badge row reflects the same spread, linking to a hosted build service, to two workflow runs on the code host, and to a third forge's own build page. Three CI systems are referenced, and the contributing text names two forges.

The code style itself is borrowed rather than invented: the project says it follows a published C++ style guide, and the repository carries both a formatter configuration and a static analysis configuration at the top level, plus an editor configuration.

For a project of this age, a mirror bot that also reformats every branch is the sort of thing that only works because a small number of people have kept it working for a long time.

The project refuses machine-generated contributions, and gives a reason

There is a section on the contributing page headed as an explicit policy about generated content, and it is a refusal rather than a preference.

It asks contributors not to submit content generated purely or largely by machine learning or large language models, and says such content will not be accepted because it conflicts with the project's objectives. Then it gives the reason: such content generally stands on dubious ethical and legal grounds, since it violates the copyright of creators whose work was scraped for a model's training data without their permission and without attribution.

That is a coherent position for a project whose content is art, text and music written by named contributors, and it is stated as a condition of contributing rather than as a preference about tooling. The interesting consequence is scope: the policy is about the content submitted, so a contributor who generates a draft and then writes it themselves is in different territory from one who submits generated text, and the page does not try to draw that line.

The rest of the contribution map is one wiki page each: scripting scenarios, art, translations, testing, and triaging issues. Five routes, five pages, and no attempt to describe the work in the repository itself.

That is the shape of this page overall. The build documentation is thorough enough to configure the project from memory, and the contribution documentation is a list of links.

The next version number is a file, and the newest tag is a rolling build

Three details close out the picture.

The first is the version scheme. The release list has a stable release, a release candidate for it from the week before, and above both a rolling tag for development builds whose timestamp matches the most recent commit rather than any release. So the newest thing you can install by tag is not a release; it is whatever the branch contained when the tag was pushed.

The second is a file at the repository root holding the next stable version number. For a project that publishes tagged releases, having the upcoming version committed is a coordination tool: it tells contributors and packagers what the next tag will be called before it exists.

The third is where the download instructions are not. The repository page does not host binaries or give you a package; it sends you to a wiki page for downloads, and the repository carries a packaging directory for one distribution family alongside a translation tool configuration, a regression test script and a separate documentation directory.

That division is deliberate and common for games: the repository is the source, the wiki is the manual, and the people who install the game are not expected to read a build option table.

Editorial conclusion

Widelands suits someone who wants a traditional economy-and-settlement strategy game they can build from source and modify, and the build documentation is good enough to do that on Linux, Windows or macOS without reading the source. Three things to check before you start. Budget for the dependency list, which includes a scripting language runtime and two alternative OpenGL binding libraries. Read the sanitizer option before your first debug build, because it is on by default and the page says turning it off is one-way without clearing the build directory. And if you contribute art, code or translations, read the project's refusal of machine-generated contributions, which it states as a condition rather than a preference.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. widelands/widelands on GitHub