No one should use any of these weird Frankenstein monstrosities in 2026. And a batch script? :( PowerShell exists.

Install:

  - contrary to the blog post, the entirety of Visual Studio, because the IDE and debugger is *really damn good*.

  - LLVM-MinGW[1]

Load the 'VSDevShell' DLL[2] for PowerShell, and you're good to go, with three different toolchains now:

  cl.exe from VS
  clang-cl.exe—you don't need to install this separately in VS; just use the above-mentioned llvm-mingw clang.exe as `clang.exe --driver=cl /winsysroot <path\to\Windows SDK> /vctoolsdir <path\to\VC>`. Or you can use it in GNU-driver-style mode, and use -Xmicrosoft-windows-sys-root. This causes it to target the Windows ABI and links against the VS SDK/VC tools
  `clang.exe` that targets the Itanium ABI and links against the MinGW libraries and LLVM libc++.

Done and dusted. Load these into a CMake toolchain and never look at them again.

People really like overcomplicating their lives.

At the same time, learn the drawbacks of all toolchains and use what is appropriate for your needs. If you want to write Windows drivers, then forget about anything non-MSVC (unless you really want to do things the hard way for the hell of it). link.exe is slow as molasses, but can do incremental linking natively. cl.exe's code gen is (sometimes) slightly worse than Clang's. The MinGW ABI does not understand things like SAL annotations[3], and this breaks very useful libraries like WIL[4] (or libraries built on top of them, like the Azure C++ SDK[5] The MinGW headers sometimes straight up miss newer features that the Windows SDK comes with, like cfapi.h[6].

[1]: https://github.com/mstorsjo/llvm-mingw

[2]: https://learn.microsoft.com/en-gb/visualstudio/ide/reference...

[3]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-...

[4]: https://github.com/microsoft/wil

[5]: https://github.com/Azure/azure-sdk-for-cpp

[6]: https://learn.microsoft.com/en-gb/windows/win32/cfapi/build-...