Toolchains don't find VS Ninja install

[aozgaa]

Building on my Win10 machine yield errors like this for all generators:

CMake Error: CMake was unable to find a build program corresponding to "Ninja Multi-Config".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
-- Configuring incomplete, errors occurred!
no such file or directory
CMake Error: Generator: execution of make failed. Make command was:  -f build-Debug.ninja
no such file or directory
CMake Error: Generator: execution of make failed. Make command was:  -f build-Release.ninja
no such file or directory
CMake Error: Generator: execution of make failed. Make command was:  -f build-RelWithDebInfo.ninja
Preset CMake variables:

This can be fixed by using the ninja.exe included with Visual Studio (Build Tools). On my machine with default install paths, it is located at:

 C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe

Or in terms of the cmake variables in the toolchain files:

${VS_INSTALLATION_PATH}\\Common7\\IDE\\CommonExtensions\\Microsoft\\CMake\\Ninja

A sample patch that searches for the VS install of ninja is available at https://github.com/aozgaa/WindowsToolchain/commit/0ec36e1b75bafcd9017ab0732863a56339657013

[MarkSchofield]

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.

[aozgaa]

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?

[MarkSchofield]

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.