Windows development¶
Windows has two maintained compiler environments with different dependency, shell, path, and artifact behavior: MSYS2/MinGW and native MSVC/vcpkg. Choose one before diagnosing a build.
Route selection¶
| Route | Contract entry | Strength | Main boundary |
|---|---|---|---|
| MSYS2/MinGW | windows-x64 or windows-tiles-sounds-x64 preset |
Unix-like shell and Ninja | MSYS2 package/runtime DLL set |
| MSVC/vcpkg | windows-x64-msvc or windows-tiles-sounds-x64-msvc preset |
Matches the Windows CI compiler lane | Visual Studio, vcpkg triplet and configuration |
| ClangCL | windows-tiles-sounds-x64-clang-cl preset |
Compiler diagnostics/time traces | Inherits the MSVC/vcpkg dependency model |
Use CMakePresets.json, .github/workflows/msvc-full-features.yml, and the applicable toolchain
files as authority. Legacy compilation prose is context, not proof that a package or command is
still supported.
Shared checklist¶
- Name the shell: PowerShell, cmd, MSYS2 MinGW64, or another environment.
- Name architecture, compiler, generator, preset, configuration, SDL version, tiles/sound, localization, tests, and static/dynamic linking.
- Keep source and build paths short enough for the selected tools and quote paths with spaces.
- Run the preset's configure and build stages in the same environment.
- Test the packaged directory, not only an executable beside development DLLs.
Artifacts and diagnostics¶
Do not commit Visual Studio output, vcpkg installations, local CMake user presets, DLL staging, PDBs, crash dumps, or credentials. PDBs, logs, package manifests, and dumps can be uploaded as restricted CI/release artifacts when needed for diagnosis.
Cross-platform boundary¶
Windows path encoding, console/SDL input, DLL discovery, and renderer recovery differ from Linux. A WSL build is a Linux binary and does not validate native Windows packaging.