Building xSTUDIO on Windows is a long manual sequence (docs/reference/build_guides/windows.md), and a few environment details that the guide cannot reasonably cover cost a lot of time when they go wrong, because they only surface deep into a multi-hour build.
The one that seems worth fixing regardless of any script:
Enter-VsDevShell and vcpkg can select different MSVC toolsets. The developer shell honours VC/Auxiliary/Build/Microsoft.VCToolsVersion.v143.default.txt, while vcpkg picks up Microsoft.VCToolsVersion.default.txt. On a machine where these differ, the vcpkg dependencies and xSTUDIO itself are compiled with different toolsets.
On my machine (VS 2022 Community, three toolsets installed) the guide as written produced:
- dependencies built with 14.42.34433
- xSTUDIO built with 14.40.33807
and, because only 14.42 shipped atlmfc, the build failed roughly 50 minutes in:
E:\...\src\audio\src\windows_audio_output_device.cpp(4): fatal error C1083:
Cannot open include file: 'atlbase.h': No such file or directory
The ATL component was installed — just not for the toolset the dev shell selected. Following the guide exactly, there is nothing to indicate this.
Two smaller ones:
- After
Enter-VsDevShell, cmake and ninja are not actually on PATH (the guide states they will be). Resolution falls through to whatever else is installed; on my machine ninja resolved to Strawberry Perl's copy, in a directory that also contains a MinGW gcc/ar.
code.videolan.org now serves an anti-bot challenge page to command-line downloads, so vcpkg's x264 fetch fails its SHA512 check. It has to be fetched once in a browser into the vcpkg downloads directory.
I have a PowerShell script that automates the guide end to end and handles the above; happy to submit it if that is useful.
Environment: Windows 10 Pro 22H2, VS 2022 Community (MSVC 14.42.34433), Qt 6.5.3 msvc2019_64, preset WinNinjaRelease.
Building xSTUDIO on Windows is a long manual sequence (
docs/reference/build_guides/windows.md), and a few environment details that the guide cannot reasonably cover cost a lot of time when they go wrong, because they only surface deep into a multi-hour build.The one that seems worth fixing regardless of any script:
Enter-VsDevShelland vcpkg can select different MSVC toolsets. The developer shell honoursVC/Auxiliary/Build/Microsoft.VCToolsVersion.v143.default.txt, while vcpkg picks upMicrosoft.VCToolsVersion.default.txt. On a machine where these differ, the vcpkg dependencies and xSTUDIO itself are compiled with different toolsets.On my machine (VS 2022 Community, three toolsets installed) the guide as written produced:
and, because only 14.42 shipped
atlmfc, the build failed roughly 50 minutes in:The ATL component was installed — just not for the toolset the dev shell selected. Following the guide exactly, there is nothing to indicate this.
Two smaller ones:
Enter-VsDevShell,cmakeandninjaare not actually onPATH(the guide states they will be). Resolution falls through to whatever else is installed; on my machineninjaresolved to Strawberry Perl's copy, in a directory that also contains a MinGWgcc/ar.code.videolan.orgnow serves an anti-bot challenge page to command-line downloads, so vcpkg'sx264fetch fails its SHA512 check. It has to be fetched once in a browser into the vcpkg downloads directory.I have a PowerShell script that automates the guide end to end and handles the above; happy to submit it if that is useful.
Environment: Windows 10 Pro 22H2, VS 2022 Community (MSVC 14.42.34433), Qt 6.5.3 msvc2019_64, preset
WinNinjaRelease.