Windows builds: toolchain and package files
MSVC/MinGW, architecture, renderers, templates and output checks.
Run commands from Source, where SConstruct lives. Configure the compiler and Windows SDK first, then choose target and arch explicitly. Build preparation covers Python/SCons requirements.
Compiler and environment
Current Source supports MSVC from Visual Studio 2019 onward, requiring at least 16.11 for the VS2019 branch. A suitable newer MSVC is selected separately from the .NET SDK. C# packages need the current managed build workflow, not just the C++ workload.
Use a terminal configured for the target architecture, such as x64 Native Tools Command Prompt for x86_64. Check Python/SCons and cl/link from the chosen toolchain. With several installations, record selected versions and environment.
| Variant | Configuration |
|---|---|
| MSVC | Normal Windows choice when found; suitable C++ components and Windows SDK |
| MinGW-w64 | use_mingw=yes with the matching compiler environment/prefix |
| LLVM within the selected family | use_llvm=yes; does not convert libraries from a different compiler/CRT |
Do not mix object files and third-party libraries with different architectures or incompatible CRTs. A linker format error calls for checking that specific library and its build rather than randomly changing arch.
Basic Windows x64 targets
python -m SCons platform=windows target=editor arch=x86_64 -j4
python -m SCons platform=windows target=template_debug arch=x86_64 -j4
python -m SCons platform=windows target=template_release arch=x86_64 -j4The first builds an editor; the next two build export templates. -j4 is an example of four jobs; reduce parallelism if memory is insufficient. Add module_mono_enabled=yes for corresponding native C# builds, then prepare managed artifacts.
These full-build commands were not executed during this verification. Options were checked against current Source; successfully building a sample extension DLL does not establish a complete Windows engine build.
Output files
Ordinary outputs go to bin. Names include windows, target, arch, optional dev/double/extra suffixes and .mono when that module is enabled. For the GUI subsystem, Source also builds a console wrapper with .console before .exe, useful for CLI logs.
Use actual filenames from the linker output. Do not promise a dependency-free single EXE: C# data, enabled SDKs/drivers and separate DLLs can be required. Retain the package and check it on the target machine.
Graphics and supporting dependencies
Current SConstruct defaults d3d12 to false. The old claim that Windows always builds Direct3D 12 support is incorrect. When enabling d3d12=yes, prepare matching MESA/NIR and selected supporting dependencies with paths/architectures appropriate to the toolchain.
ANGLE, AccessKit, Agility SDK and PIX have separate options/paths. Check configuration logs: a missing optional dependency can disable a feature, and a successful compile does not establish its presence. When needed, inspect the current tree’s relevant installer script before using it; these installers were not run in this verification.
Disabling one driver does not establish another: check resulting rendering_device, forward_plus_renderer/forward_mobile_renderer, vulkan and opengl3 against project needs. A copied flag list is not a renderer test.
Optimization and acceptance
production=yes selects platform defaults; current MSVC detect.py maps lto=auto to none. Symbols, optimize and dev_build are separate options. See SCons configuration.
After your build, check editor startup, project creation/opening, the required renderer, C# when used and an actual exported game with its correct template. Record tool versions, options and output hashes. This verification did not perform complete Windows-package acceptance.