Write note in README/docs that if you want to use a custom build LLVM/Clang with "clang-cl", you need to symlink it to VS "\VC\Tools\Llvm"

[GavinRay97]

I couldn't get this extension detecting my custom built LLVM 13 clang-cl.exe.

It detected everything else, including the Visual Studio clang-cl you are forced to install if you want LLVM/clang compatibility, and the regular clang.exe for my LLVM 13, but not the clang-cl.exe

Then I found a comment from someone referencing a commit which was meant to fix an issue with clang-cl detection, and I found that it appeared to be checking that the path to the binary was inside of a Visual Studio install LLVM tools:

const clangArch = (vs_arch === "amd64") ? "x64\\" : ""; 
if (binPath.startsWith(`${vs.installationPath}\\VC\\Tools\\Llvm\\${clangArch}bin`) && 

So I tried this:

mklink /D `
  "C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\Llvm\x64\bin\13" ` 
  "C:\Users\rayga\Projects\tmp\llvm-project\llvm-13.0.0-msbuild-vs2019-x64-rel\bin"

And then:

Out of curiosity, why can't this do:

const pathString = await spawn(['echo', isWindows ? '%PATH%' : '$PATH'])
const pathBinaries = pathString.split(";")
const clangClBinaries = pathBinaries.filter(it => it.endsWith(isWindows ? "clang-cl.exe" : "clang-cl"))

Instead of requiring it to be inside of Visual Studio?

https://github.com/microsoft/vscode-cmake-tools/blob/42933885019e9538678cd6dca45836bfd86f96c8/src/kit.ts#L925-L989

[bobbrow]

I think @andreeis knows more about this code than I do, but I don't see any reason why we shouldn't be checking the PATH here. I believe the code that calls into this function includes non-VS search paths as well.

We'd be open to a PR here if you have a fix, though I would recommend using the which node module to look up an executable from the PATH instead of spawning an echo. (import * as which from 'which'; should work since we use it elsewhere)

[GavinRay97]

Maybe there's a backstory/technical details behind why this only searches VS install directories for clang-cl.exe.

One thing is that clang-cl.exe is practically worthless without sourcing vcvars${arch}.bat in the current environment so that the MS tooling and environment variables are all set up. Pretty much nothing will work.

You need to set up proper includes, which means setting up .vscode/cmake_kits.json like:

{
    "name": "Clang 13.0.0 (clang-cl.exe, MSVC CLI) x64",
    "compilers": {
      "C": "C:\\Users\\rayga\\Projects\\tmp\\llvm-project\\llvm-13.0.0-msbuild-vs2019-x64-rel\\bin\\clang-cl.exe",
      "CXX": "C:\\Users\\rayga\\Projects\\tmp\\llvm-project\\llvm-13.0.0-msbuild-vs2019-x64-rel\\bin\\clang-cl.exe"
    },
    "environmentSetupScript": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Preview\\VC\\Auxiliary\\Build\\vcvars64.bat",
    "cmakeSettings": {
      "CMAKE_C_FLAGS": "/DWIN32 /D_WINDOWS /W3 -m64",
      "CMAKE_CXX_FLAGS": "/DWIN32 /D_WINDOWS /W3 -m64",
      "CMAKE_EXE_LINKER_FLAGS": "/machine:X64",
      "CMAKE_MODULE_LINKER_FLAGS": "/machine:X64",
      "CMAKE_SHARED_LINKER_FLAGS": "/machine:X64",
      "CMAKE_STATIC_LINKER_FLAGS": "/machine:X64"
    }
  }

So maybe it's the case that elsewhere in the code, for clang-cl.exe MSVC style it uses a relative path to get vcvars? Not sure 🤔

[Zingam]

@GavinRay97 Did you try setting LLVM_ROOT or something? I don't remember.

[andreeis]

@GavinRay97, without the code you reference (about checking clang-cl to be inside the Visual Studio installation path), the extension would always find the same first clang* toolset in the path and associate it with every different Visual Studio release. You wouldn't be able to exercise the correct clang* binaries for one given VS version. And when detecting clang for VS, we automatically run vcvars as well (isn't that so?).

From reading your scenario, it looks that we can also support searching for clang in all the paths found in the PATH environment variable and we can add some kits for those too (but we wouldn't know which vcvars to set as setup script).

Also, editing the kits definitions in .vscode/cmake-kits.json (or even the main cmake-tools-kits.json) is acceptable I think for special scenarios like this.

[mitsukuri]

+1 vote for proper detecton of clang-cl in custom locations

[github-actions[bot]]

This issue is now marked as 'stale-old' due to there being no activity on it for the past 720 days. Unless the 'stale-old' label is removed or the issue is commented on, this will be remain open for at least 14 days and then it may be closed. If you would like to make this issue exempt from getting stale, please add the 'stale-exempt' label.

[cctv130]

Can we add the environmentSetupScript variable to launch.json?

[gcampbell-msft]

@cctv130 Thanks for the comment, for us to best track this, could you please create an issue with a description of your desired scenario and your request?

Thanks.