v0.14.0

Notable Fixes

• Windows.Clang.toolchain.cmake can be used on Linux to cross-compile to Windows, with the MSVC Toolset, Windows SDK present
• Windows.Clang.toolchain.cmake correctly cross-compiles on Windows
• When using the Visual Studio distributed 'LLVM' toolset, the ARM64 build will be preferred on an ARM64 host.

What's Changed

• Update 'example/build.ps1' with correct preset names in #146
• Use 'winget' to install cuda in #147
• Windows.Clang.toolchain.cmake should accommodate VS_INSTALLATION_PATH being set in #149
• Align the CMAKE_TRY_COMPILE_PLATFORM_VARIABLES between *.toolchain.cmake files in #151
• Accommodate more variables being set by callers (for MT, RC, C- and C++- compilers) in #152
• Support Windows.Clang.toolchain.cmake and Windows.Kits.cmake consumption from Linux in #153
• Specify CMAKE_<LANG>_COMPILER_TARGET reflecting CMAKE_SYSTEM_PROCESSOR in #157
• Prefer the arm64 Visual Studio clang on ARM64 in #159
• Add vs2026 presets; use the 'windows-2025-vs2026' runner image in #154
• Consolidate CMAKE_${LANG}_COMPILER_TARGET logic in Windows.Clang.toolchain.cmake in #160

Full Changelog: v0.13.0...v0.14.0

v0.13.0

This release contains a few fixes from the community - thanks to @fredericouellet-eaton and @hadogenes for contributing! - and a fix that unblocks FASTBuild generator support.

What's Changed

• Append to CMAKE_TRY_COMPILE_PLATFORM_VARIABLES instead of overwritting it by @fredericouellet-eaton in #125
• Allow opt-ing out of adding the VS-redistributed ninja to the CMAKE_SYSTEM_PROGRAM_PATH by @MarkSchofield in #126
• Remove warnings for deprecated constructs/variables by @MarkSchofield in #128
• Set CMAKE__COMPILER_PREDEFINES_COMMAND in Windows.MSVC.toolchain.cmake by @hadogenes in #129
• Windows.Clang.toolchain.cmake should use 'CMAKE_VS_PRODUCTS' by @MarkSchofield in #132
• Update VS generators to Windows SDK 10.0.26100.0; allow Toolchain to find 10.0.26100.0 by @MarkSchofield in #134
• Update CMAKE_VS_VERSION_RANGE to '[16.0,19.0)' to include VS2026 by @MarkSchofield in https://github.com//pull/138
• Fixes to 'Windows.EWDK.toolchain.cmake' by @MarkSchofield in #137
• Cleanup presets; add more verbose preset names by @MarkSchofield in #139
• Support for the FASTBuild generators by @MarkSchofield in #141

New Contributors

• @fredericouellet-eaton made their first contribution in #125
• @hadogenes made their first contribution in #129

Full Changelog: v0.12.0...v0.13.0

v0.12.0

This release contains fixes for ASM compilation, and in the configuration of CMAKE_CROSSCOMPILING. The Toolchains will also include Visual Studio and Windows SDK paths in the CMAKE_PROGRAM_PATH so that other tooling can be found, and the path to the 'Visual Studio'-distributed 'Ninja' (if present) in the CMAKE_SYSTEM_PROGRAM_PATH path to allow CMake to find ninja, if it isn't otherwise found.

Thanks to all of the folks who contributed - through fixes, filing issues, or discussions!

What's Changed

• Fix a few problems in the windows-vs-* presets by @MarkSchofield in #109
• CUDA only supports x64 compilation; exclude the Cuda example from non-x64 builds by @MarkSchofield in #110
• Add standard includes for ASM by @paulfd in #117
• Include the VS toolset and Win32 SDK binary paths in the CMAKE_PROGRAM_PATH by @MarkSchofield in #119
• Add an example that builds .asm files by @MarkSchofield in #118
• Consider the Visual Studio path for Ninja by @MarkSchofield in #120
• CMAKE_CROSSCOMPILING should not be true, if the build targets the host processor by @MarkSchofield in #124
• Pass '/X' to ensure that msvc doesn't use include paths from the environment by @MarkSchofield in #122

New Contributors

• @paulfd made their first contribution in #117

Full Changelog: v0.11.0...v0.12.0

v0.11.0

WindowsToolchain hasn't been strict enough in its handling of CMAKE_SYSTEM_PROCESSOR, and this release starts to fix this. 'CMAKE_SYSTEM_PROCESSOR' on Windows should be one of: AMD64, X86, ARM, ARM64, but WindowsToolchain allowed x64 (for AMD64) and x86, arm, arm64 (for their upper-case counterparts). With this release, using anything but the correct values will result in a warning. I've updated the example to only use correct values. Sorry if this causes fall-out, but getting things correct seems to be better than continuing with ambiguity.

What's Changed

• Standardize 'CMAKE_SYSTEM_PROCESSOR' values by @MarkSchofield in #108

Full Changelog: v0.10.0...v0.11.0

v0.10.0

What's Changed

• Prefer the 'arm64' host compiler on ARM64 hosts by @MarkSchofield in #96
  • ARM64 machines should see slightly better performance when compiling and linking.
• Modified Clang toolchain to find correct path Issue #97 by @aboelens in #98
  • The Windows.Clang.toolchain.cmake wasn't correctly setting the CRT library path and was relying on clang-behavior/environment. The toolchain now configures the necessary paths explicitly.
• Remove references to Pester tests by @MarkSchofield in #102
• Add 'CUDA' awareness by @MarkSchofield in #106
  • Thanks to @bowie7070 for helping identify the problem and iterate on the solution.
  • The 'example' folder now includes a sample that uses CUDA.

New Contributors

• @aboelens made their first contribution in #98
• @bowie7070 contributed to #106

Full Changelog: v0.9.0...v0.10.0

v0.9.0

This release has a couple of notable changes:

1. The MSVC toolchains - Windows.MSVC.toolchain.cmake and Windows.EWDK.toolchain.cmake - were not configuring a handful of MSVC-related CMake variables correctly - including MSVC_TOOLKIT_VERSION. With this release the toolchain files rely on CMake infrastructure to ensure that the variables are set correctly.
2. The VS_USE_SPECTRE_MITIGATION_RUNTIME option will now log an error if the necessary Visual Studio component is not installed. Previously the non-existent path was used, and linker errors would have been reported by the linker.

Important

The VS_USE_SPECTRE_MITIGATION_RUNTIME option no longer controls the use the of ATL/MFC Spectre-mitigation runtime; the new VS_USE_SPECTRE_MITIGATION_ATLMFC_RUNTIME needs to be set to get the ATL/MFC Spectre-mitigation runtime. Without this setting consumers will use the non-Spectre-mitigation ATL/MFC runtime if it is installed with Visual Studio.

What's Changed

• Windows.Clang.toolchain.cmake need not set CMAKE_<LANG>_COMPILER_ID and CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT by @MarkSchofield in #86
• Avoid setting MSVC_VERSION in the toolchain, rely on CMake setting it (and others) by @MarkSchofield in #91
• VS_USE_SPECTRE_MITIGATION_RUNTIME should prefer the Spectre library path, not use it exclusively by @MarkSchofield in #73
• Add 'app.manifest' to example/WindowsApplication, mark as DPI aware by @MarkSchofield in #92
• Change example defaults to build by default by @MarkSchofield in #94
• Windows.MSVC.toolchain.cmake shouldn't fallback to non-Spectre folders on Spectre builds by @MarkSchofield in #95

Full Changelog: v0.8.0...v0.9.0

v0.8.0

This release includes a couple of fixes, and one main feature: support for the "Enterprise Windows Driver Kit" build environment.

What's Changed

• Fix regex to get MSVC version by @scott-degraw in #75
• Bump actions/checkout from 3 to 4 by @dependabot in #76
• Add support for settable VS_INSTALLATION_PATH - enabling eWDK by @kaloth in #74
• Fix 'VS_PLATFORM_TOOLSET_VERSION' logic for setting the toolset version by @MarkSchofield in #80
  • In previous versions you could set the version of the MSVC to use by setting both VS_PLATFORM_TOOLSET_VERSION and VS_TOOLSET_VERSION. WindowsToolchain now just uses VS_PLATFORM_TOOLSET_VERSION.
• Add a Windows.EWDK.toolchain.cmake by @MarkSchofield in #77
• Fix build breaks in .github/workflows/ci.yaml by @MarkSchofield in #84

New Contributors

• @scott-degraw made their first contribution in #75
• @dependabot made their first contribution in #76
• @kaloth made their first contribution in #74

Full Changelog: v0.7.0...v0.8.0

v0.7.0

This release is the first of the more scoped WindowsToolchain - the Windows-specific build logic has moved to the WindowsCMake repository to reduce the surface area of the WindowsToolchian repository. Discussion 65 covers the details of the change.

What's Changed

• Update VCPkg documentation with 'VCPKG_CHAINLOAD_TOOLCHAIN_FILE' details - #64
• Run cmake-lint on all '*.cmake' and 'CMakeList.txt' files - #68
• Replace include_directories by CMAKE_${LANG}_STANDARD_INCLUDE_DIRECTORIES - #69
• Remove non-Toolchain content by - #66
• Avoid add_compile_options in the toolchain file - #71

Full Changelog: v0.6.0...v0.7.0

v0.6.0

A release that fixes Windows.MSVC.toolchain.cmake on non-English localizations, and includes a few behind-the-scenes test and linting changes.

What's Changed

• Adding an initial '.cmake-format.yaml' by @MarkSchofield in #51
• Add tests that validate Ninja and NuGet behavior by @MarkSchofield in #52
• Tests should preserve and restore Location by @MarkSchofield in #54
• Add 'add_import_library' for generating an import library from a list of exports by @MarkSchofield in #53
• 'install_nuget_package' doesn't honor PACKAGESAVEMODE by @MarkSchofield in #56
• Add 'VS_EXPERIMENTAL_MODULE' to control whether '/experimental:module' should be enabled by @MarkSchofield in #60
• Add documentation on using VCPkg and WindowsToolchain together by @MarkSchofield in #61
• Use a more generic regex to get msvc version by @FeignClaims in #62

New Contributors

• @FeignClaims made their first contribution in #62

Full Changelog: v0.5.1...v0.6.0

v0.5.1

The v0.5.1 release includes a couple of fixes on-top of v0.5.0, based on feedback and discussion.

What's Changed

• WindowsToolchain files should no-op on non-Windows by @MarkSchofield in #45
• Refactor find_program usage by @ClausKlein in #49
• 'VSWhere.cmake' and 'NuGet.cmake' should do no work by default by @MarkSchofield in #46

New Contributors

• Thanks to @ClausKlein, who made their first contribution in #49

Full Changelog: v0.5.0...v0.5.1