Visual C++ Support may not reliably detect MSVC

[azuo]

Currently, org.eclipse.cdt.internal.msw.build.VSInstallationRegistry detects the VS installation path using the following command line:

vswhere -version [m,n] -property installationPath

However, this may not be perfect in some cases - for example, it will ignore a tools-only installation with MSBuild + VC but no IDE. (but instead unnecessarily detect a VS installation without VC?)

Referring to https://github.com/microsoft/vswhere/wiki/Find-VC, is it more reliable to switch to the following command line?

vswhere -version [m,n] -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath

Or, more generally:

vswhere -version [m,n] -products * -requires Microsoft.VisualStudio.Component.VC.Tools.* -property installationPath

[MarkZ3]

This makes sense. I would say sticking to x86.x64 for now since the plugin doesn't support other targets (there is no mechanism to select something else). If you make a MR I will test it.

[chirontt]

I would say sticking to x86.x64 for now

But this change suddenly makes it unusable on Windows on Arm64 (WoA) box, while the existing command:

vswhere -version [m,n] -property installationPath

does work on WoA. Should it be retained in preparation for WoA support in CDT? I'm willing to help in this WoA support in CDT.

(FYI: Eclipse IDE 2024-12 now has packages for WoA, including the C/C++ Development package:

)

[MarkZ3]

does work on WoA.

I expect you would get the x86.64 target toolchain detected. So cross compiling x86.64 from Arm, along with matching defines, etc.

But this change suddenly makes it unusable on Windows on Arm64 (WoA) box

I don't think so, it means we only support targeting x86.x64 but the host architecture should not matter. There is already several places in the plugin that has x86.x64/amd64 target hardcoded (vcvars, defines). I would suggest using Component.VC.Tools.x86.x64 until there is a UI to select arm target then adjust the command.

Alternatively we could assume host == target and only support targeting arm on arm host and targeting x86 on x86. But it would require more changes and I don't have a Arm64 Windows host to test. I think it would be pretty easy to check the osgi running host architecture and use that knowledge in the couple of places that x86/amd64 is currently hardcoded. No UI would be needed although not very flexible.

[chirontt]

@MarkZ3 I think you've misunderstood me completely. And perhaps I also misunderstood the purpose of this command:

vswhere -version [m,n] -property installationPath

used in the CDT code. As far as I can see the CDT doesn't detect MSVC as a valid toolchain at all on my Windows x64 box nor on my WoA box, let alone any cross-compile ability on either boxes. (FYI, no GCC tools are present.) Plus the CDT is missing a native plugin for WoA, so no compile/build/make is possible (i.e. missing the spawner.dll binary for WoA). But I'll create some separate issue/PR for it, to avoid hijacking this issue here.

[MarkZ3]

I'm not sure why the current command would work for WoA but not x64 for you. Perhaps there are components missing in your VS installation on the x64 box? More investigation would be needed. Does it display something when you run it on the command-line? Once an installation is found, it runs \VC\Auxiliary\Build\vcvarsall.bat amd64 under the installation folder, to fetch INCLUDE, LIB, PATH.
See VSInstallationRegistry.detectVSInstallation and VSInstallation.detectToolchains for good spots to debug this.

(The missing cdt.core fragment is another topic/issue yes).

[MarkZ3]

Hmm, yes I'm confused. Your first message says the command works on WoA and the second says it doesn't. Maybe you mean using the original command could work whereas the new command wouldn't?