It turns out that #107 was perhaps a bit rushed. Here's some fixes from trying out the presets:
'windows-vs-*' preset should inherit from 'windows-vs' - I typo'd. The 'windows-vs-*' presets should've inherited from 'windows-vs' - just to follow the precedent I've set-up in CMakePresets.json. 'windows-vs' was just setting the generator as 'Visual Studio 17 2022', which - it turns out - is the default on Windows, so there's no functional difference here. But being explicit in the generator would be my preference, to make sure that folks don't accidentally pick-up a new one on CMake update.
_Set the windows-vs* target architecture using 'CMAKE_GENERATOR_PLATFORM', not 'CMAKE_SYSTEMPROCESSOR' - The Visual Studio Generators expect CMAKE_GENERATOR_PLATFORM to set the target processor architecture, not CMAKE_SYSTEM_PROCESSOR. Again (since I'm building on x64), the default made me think it was working. The ARM64 build, however, was building for x64, which is broken. The Visual Studio Generators also get told of the Windows SDK through the CMAKE_GENERATOR_PLATFORM value, which I hadn't realized. It's a bit awkward - it makes it harder to configure/choose an SDK, but I suppose it's at least clear.
_Use CMAKE_SYSTEMPROCESSOR 'X86', not 'x86' I should've cleaned-up my x86CMAKE_SYSTEM_PROCESSOR value to X86. Fixing that now.
Give the windows-vs-* presets better names - I've been using VSCode's CMake support a bit more (not just command-line CMake'ing), and the displayName of the preset is surfaced prominently, and highlights that the values weren't particularly useful. Fixing that.
It turns out that #107 was perhaps a bit rushed. Here's some fixes from trying out the presets:
'windows-vs-*' preset should inherit from 'windows-vs' - I typo'd. The 'windows-vs-*' presets should've inherited from 'windows-vs' - just to follow the precedent I've set-up in
CMakePresets.json. 'windows-vs' was just setting the generator as 'Visual Studio 17 2022', which - it turns out - is the default on Windows, so there's no functional difference here. But being explicit in the generator would be my preference, to make sure that folks don't accidentally pick-up a new one on CMake update._Set the windows-vs* target architecture using 'CMAKE_GENERATOR_PLATFORM', not 'CMAKE_SYSTEMPROCESSOR' - The Visual Studio Generators expect
CMAKE_GENERATOR_PLATFORMto set the target processor architecture, notCMAKE_SYSTEM_PROCESSOR. Again (since I'm building on x64), the default made me think it was working. The ARM64 build, however, was building for x64, which is broken. The Visual Studio Generators also get told of the Windows SDK through theCMAKE_GENERATOR_PLATFORMvalue, which I hadn't realized. It's a bit awkward - it makes it harder to configure/choose an SDK, but I suppose it's at least clear._Use CMAKE_SYSTEMPROCESSOR 'X86', not 'x86' I should've cleaned-up my
x86CMAKE_SYSTEM_PROCESSORvalue toX86. Fixing that now.Give the windows-vs-* presets better names - I've been using VSCode's CMake support a bit more (not just command-line CMake'ing), and the
displayNameof the preset is surfaced prominently, and highlights that the values weren't particularly useful. Fixing that.