Thanks for filing the issue, @aozgaa, and for the fix! I actually split out the 'ninja download' piece out of WindowsToolchain a short time ago - it's discussed in #65, and then implemented in #66. That means that WindowsToolchain is purely a CMake toolchain, and optional things - like Ninja download - got moved to MarkSchofield/WindowsCMake. Teaching MarkSchofield/WindowsCMake about the Visual Studio distributed ninja seems reasonable.

I wasn't aware that the generator doesn't fit in the toolchain, nor had I seen the WindowsCMake repo previously.

On reflection this makes conceptual sense though. Toolchains and generators seem to be orthogonal in the cmake documentation: cmake-toolchains(7) and cmake-generators(7).

As a partical matter then, in order to drive build with ninja on windows, a user would either need to
a) separately install ninja / add it to $env:PATH
b) use both WindowsToolchain and WindowsCMake to get both a toolchain and generator.

Does that sound right?

As an implementation complication -- in order to find ninja in a robust way, we need to find the visual studio installation, which is basically reimplementing/referencing VSWHERE in the other repo. I don't see references/depedency between the repos from a cursory glance but I could be mistaken.

Can you advise on how you'd like that done?

I wasn't aware that the generator doesn't fit in the toolchain, nor had I seen the WindowsCMake repo previously.

Sorry! In order to bring more focus (and less churn) to WindowsToolchain, I added a stricter definition of responsibilities.

As a partical matter then, in order to drive build with ninja on windows, a user would either need to
a) separately install ninja / add it to $env:PATH
b) use both WindowsToolchain and WindowsCMake to get both a toolchain and generator.

Yes. To add context:

1. separately install ninja / add it to $env:PATH - These days I just winget install Ninja-build.Ninja --source winget to do that. I believe chocolatey can do that, too. Or scoop.
2. use both WindowsToolchain and WindowsCMake to get both a toolchain and generator - Yes. I submodule both WindowsToolchain and WindowsCMake, then - before the first project call, do something like:

include(${WINDOWSCMAKE_DIR}/Ninja.cmake)

As an implementation complication -- in order to find ninja in a robust way, we need to find the visual studio installation, which is basically reimplementing/referencing VSWHERE in the other repo. I don't see references/depedency between the repos from a cursory glance but I could be mistaken.

At the minute, WindowsCMake does rely on CMake variables from WindowsToolchain - for example, for midl.exe invocation, WindowsCMake's WindowsCMake\Midl.cmake uses the MIDL_COMPILER CMake variable that WindowsToolchain's Windows.Kits.cmake sets. But there's two problems:

1. WindowsToolchain doesn't set any documented variables related to the location of Visual Studio. Technically, it sets, say, VS_INSTALLATION_VERSION and VS_INSTALLATION_PATH, but they're not documented as being set.
2. There's an ordering problem. If a WindowsToolchain is specified as a toolchain, it will be parsed by CMake when the first project call is made. But ${WINDOWSCMAKE_DIR}/Ninja.cmake needs to act before the first project call is made, so can't rely on properties that the toolchain sets. So - best case - it has to find VS again, duplicating work that the toolchain will do...? And for that ${WINDOWSCMAKE_DIR}/Ninja.cmake would need to depend on VSWhere.cmake from WindowsToolchain.

So it's a bit tricky. Since my goal with WindowsToolchain was to lower the barrier to entry for using CMake on Windows, by making it more Linux/Unix/MacOS-like, and in those cases, a user would be expected to have the 'generator' installed already, I'm not sure it's worth heroics to get this working.