Offer to set Ninja as preferred generator when present

[bobbrow]

This change (to use Visual Studio as a generator instead of Ninja when compiling with MSVC) has broken my build environment :(. This was is a breaking change but doesn't appear to have been treated as such.

This was also previously advertised as a feature of this extension, per the documentation linked in the extension's homepage.

https://vector-of-bool.github.io/docs/vscode-cmake-tools/kits.html#kits

Quote:

If you use Ninja there is no need to worry about Visual Studio CMake Generators. CMake Tools will prefer Ninja if it is present unless configured otherwise.

Originally posted by Stuart Alldritt (@skalldri) in #1084 (comment)

[bobbrow]

We have settings that should allow you to change the default behavior. The problem was that the order in which these options were processed and the default value set for them made it difficult to enable Visual Studio as the default generator for those who preferred it (and there was a bug in the process of scanning for kits). That was what #1084 was attempting to solve.

I can also see this from your point of view where you would prefer Ninja over Visual Studio. The settings should allow you to get that behavior. Set "cmake.preferredGenerators": [ "Ninja" ] and you should get the previous behavior.

That said, perhaps we should add a feature that detects Ninja up front and asks you if you prefer using that over Visual Studio. Depending on your response, the extension can set cmake.preferredGenerators for you. Does that sound like it would be an acceptable way to address this problem?

[skalldri]

I can also see this from your point of view where you would prefer Ninja over Visual Studio.

To clarify, this isn't a preference, it's a requirement for my build environment. Switching to Visual Studio as the generator for my project causes it to simply stop building entirely. There are lots of custom build steps to run utility applications and code generators in my CMake project, and the build fails catastrophically when it tries to execute some of them. It seems to have an especially hard time running any of the Node.js-based code generator tools.

The build process also took significantly longer to run, even for the parts that worked correctly.

That said, perhaps we should add a feature that detects Ninja up front and asks you if you prefer using that over Visual Studio.

That would be nice. It was a very strange experience to delete my build folder and suddenly be unable to complete the configure step for my project anymore, on branches that had been working just fine for months. Especially given that this was a change to the default behavior, I would have liked some better notification that something was different.

[bobbrow]

To clarify, this isn't a preference, it's a requirement for my build environment.

Are you able to unblock your build by using the cmake.preferredGenerators setting as described above? My first concern is that you have a way to continue to be productive while we sort this out.

EDIT: cmake.preferredGenerators is likely the way we will continue to support this. The only additional change we'd plan to make would be to assist you in setting that setting if we detect Ninja.

[skalldri]

Ah yes! Sorry, I didn't make that clear. I've tested both cmake.generator and cmake.preferredGenerators, and they will both successfully to force it back to using Ninja + MSVC.

[seanmiddleditch]

I would find it odd to default to preferring the MSVC project generator when even Visual Studio proper itself defaults to a Ninja-based builds for CMake projects. I would think that VSCode would want to be as consistent as possible with VS, especially with other requests like #529 .

I'd much rather see vscode-cmake-tools include a copy of ninja and just use that for default Windows builds, same as VS does, and require explicit opt-in to use either msbuild or a custom copy of ninja. Consistency in Windows tooling being the goal.

[seanmiddleditch]

Self-reply (sorry...)

I'd much rather see vscode-cmake-tools include a copy of ninja and just use that for default Windows builds, same as VS does

Since VS actually includes a copy of ninja itself (bundled in the CMake directory, even), it should just use that if using the cl.exe compilers or bundled cmake.exe:

ex:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.exe

[skalldri]

Poking for visibility. I just got bitten by this again on a new machine I'm setting up for the same project. Thankfully I remembered this issue to help me remember how to solve it...