Sources: Makefile CMakePresets.json doc/c++/COMPILING.md commit d32b9cc880a8 build-config

WSL development

WSL runs the Linux toolchain on a Windows host. It is useful for Linux builds and tests, but it does not produce evidence for native MSVC/MinGW packaging, Windows DLL discovery, or the native Windows console/input path.

Choose the filesystem deliberately

Linux builds are usually faster and have more predictable permissions inside the WSL Linux filesystem than under /mnt/c. Record whether the checkout and build directory live on the Linux or mounted Windows filesystem; case sensitivity, executable bits, file watching, and path translation can change the failure mode.

Build route

Use the Linux contracts from Makefile or CMakePresets.json, not a Windows preset:

cmake --list-presets
cmake --preset linux-x64
cmake --build --preset linux-x64

For tiles, sound, or a launched game, separately document WSL version, graphics integration, display/audio environment, GPU/driver path, and SDL version. A successful headless curses test does not validate those layers.

Validation boundary

Report Windows version, WSL version/distribution, filesystem location, compiler, preset/flags, and whether the binary was only tested inside WSL. Validate line endings and executable bits in Git, but do not add platform-generated files or local mount paths to the repository.

Common failures

Slow metadata access on mounted drives, Windows tools accidentally first on PATH, CRLF shell scripts, unavailable GUI/audio sockets, and memory limits need different fixes. Reproduce in a native Linux CI lane when determining whether a failure is CCB code or WSL integration.