MSVC: Use bundled CMake if present and no other is in path

[knopp]

MSVC already comes with CMake installed (by default if desktop development with c++ was specified), but CMake-rs doesn't know about it.

This PR will use the bundled installation, but only if there is no other CMake installation in path.

[alexcrichton]

Is there documentation to link to of how this is found? Otherwise all I can really do is rubber-stamp this as I don't really have any idea if this is correct and there's not really a great way to test this on CI

[knopp]

I don't think there's any official documentation mentioning CMake installation location. It just happen to be for last few MSVC versions. For example flutter tool which invokes during build locates it same way.

[knopp]

This may need some work. If there are multiple VS versions installed side by side (i.e. 2019 and 2022) this finds CMake from 2019, but will fail because it tries to use it with 2022 generator.

[alexcrichton]

Ok, sorry but I've decided that I will no longer maintain this crate and it needs a new maintainer.

[shuffle2]

Another issue with the proposed implementation (and which I had in my first try) is that you cannot rely on devenv.exe being present (e.g. if only Build Tools are installed). It seems the correct way is to use the related COM interface to get the base directory and then append Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe.

Note you can also use ISetupInstance2.GetPackages to check if the cmake package (Microsoft.VisualStudio.VC.CMake) is installed and query some info about it if desired (of course, it doesn't give you any path information about the installed cmake though, that would be too helpful :))

In any case, the cc crate should probably just expose ability to get the root installation directory corresponding to the resolved cl.exe such that users of that crate can tack on any paths they want without having to reimplement all the COM stuff or relying on cc to implement detection of every possible binary distributed with msvc.

[the-Arioch]

Can the CMAKE_COMMAND env-var be used ? it seems to be a standard (albeit hard to find) way?

https://cmake.org/cmake/help/latest/variable/CMAKE_COMMAND.html

I would maybe also look into https://cmake.org/cmake/help/latest/variable/CMAKE_VS_DEVENV_COMMAND.html

I have a similar, perhaps, case whgen a newb run into a wall: DDoSolitary/yasfw#49

However i do not have giant VS IDE amd instead try to wrap my mind around VC++ Build Tools and VSCode
In my case it is MS Visual Studio Build Tools 2019 version 16.11.12

I also just had installed VCPKG.

Now i seem to have two CMAKE instances:

c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe
d:\CppProjects\VCPKG\downloads\tools\cmake-3.22.2-windows\cmake-3.22.2-windows-i386\bin\cmake.exe 

Looks kind of redundant and weird, but that is how Microsoft is making it yet.
The latter can be optimistically found using another env-var VCPKG_ROOT=d:\CppProjects\VCPKG\, but this does not seem a good solution.
Perhaps there can be some newb-oriented document how to install or find CMAKE tool, and the library refer to it when spewing "not found" error, instead of letting novice users out in the dark.

---

A faux path would be to rely on the standard Windows sequence of finding an application by document file extension. To me HKEY_CLASSES_ROOT\.cmake registry branch finally led me to VSCode editor, to to cmake processor.

[shuffle2]

fwiw here's how i've solved it (works for VS or BuildTools-only installs) https://github.com/unicorn-engine/unicorn/blob/2912cd1e299456e71f9fc52b046d84cf1aff2144/bindings/rust/build.rs#L21

[the-Arioch]

This seems to be related to #142

Just cross-linking two discussion pages, making it easier to find

[thomcc]

Mind rebasing to fix conflicts? This path seems right to me (matches the path on my windows machine, and the path that other projects seem to have used for some time without problems).

[ChrisDenton]

I do think cc-rs should have a proper way to get the base directory but an interim solution does make sense.