How to get cmake-tools work with toolchain installation (like MSYS2) without putting the whole toolchain on PATH?

[ToBoMi]

Brief Issue Summary

I cannot get cmake-tools to work with a toolchain installation (like MSYS2) without putting the whole toolchain on the PATH.

The only way to get cmake-tools work with the MSYS2 installation in the standard installation folder C:\msys64\mingw64\bin is to add it to the PATH variable (of the user) outside vscode.
That is fine as long as there are no multiple toolchains in different versions used. vscode would detect them and lets one select the right one, but other tools are different.
Maybe this is something to talk about because this might be the wrong view on things. Perhaps I should expect other tools to handle such a situation correctly and stop using tools that don't. But sometimes you may want a specific toolchain to be on the path for a terminal to just call cmake and then it might be the wrong cmake version.

There seem to be many other ways to make the cmake tools kit search detect kits. I am unable to get one of them working. They are:

• Use the MinGW search dirs in cmake tools settings
• Set up your kit manually in cmake-kits.json (This is something I would rather not use since there is a detecting mechanism that can define the settings better than I can do manually)
• Set up additional kits path in cmake tools settings
• Add the MinGW path in vscode internally (See this stackoverflow suggestion)

Before one wants to go into details on each of the other possibilities and why they don't work for me, can we please discuss in general:

1. Is it intended to get it done without using the PATHvariable?
2. If there is no other way planned than using the PATH: Why is that not a problem with other tools using the PATHvariable?
3. What other option should be used for my use case?

CMake Tools Diagnostics

Logs as needed, this is more a question currently

Debug Log

Logs as needed, this is more a question currently

[bobbrow]

Just to make sure we're talking about the same thing... When you say "toolchain" are you talking about CMake Toolchains, or are you referring to the compiler? We don't have any sort of CMake toolchain detection. These always require creating a "Kit" to establish (or use the cmake.configureSettings to set the CMAKE_TOOLCHAIN_FILE).

If you add CMT_MINGW_PATH to the environmentVariables section of the kit, you should be able to set the path there instead of in your shell. CMake Tools' compiler detection for MinGW compilers should be doing this for the Kits (compilers) that are detected. If not, then it's possible we need to do something extra for msys2 that's not currently being done.

[ToBoMi]

When I said "toolchain" I mean the bin folder of a MinGW installation. I don't know what toolchain exactly means in terms of cmake and only a compiler is not enough.
I wrote "toolchain" because a bin folder of a MinGW (MSYS2, too) installation there is not only the compiler, but beside other things for example the cmake executable.

If you add CMT_MINGW_PATH to the environmentVariables section of the kit, you should be able to set the path there instead of in your shell

Will try that soon.

CMake Tools' compiler detection for MinGW compilers should be doing this for the Kits (compilers) that are detected. If not, then it's possible we need to do something extra for msys2 that's not currently being done.

I have no idea how this works, but kit creation is something I don't know and having just the path entered and cmak-tools finds "everything" seems more desireable, thats why I like the using CMT_MINGW_PATH more.

[nidefawl]

Is CMT_MINGW_PATH appended to the configuration environment only?
Or is it also used for the Debug and Run environment?

I use this toolchain: https://github.com/mstorsjo/llvm-mingw
The only thing I need on my path for building is ninja.exe and cmake/bin.
The toolchain is not on the path, it is configured in my cmake kits json. I use several different version of the toolchain I built myself.

This works well for building. But the dependencies for executing my application are in the toolchain/x86_64-w64-mingw32 directory. (In this case libc++.dll and libunwind.dll, which contain the mingw64 crt runtime. These are equivalent to msys-2.0.dll that you need to execute msys 2 built programs)

So when I switch compilers I still have to exit VSCode and make it set the correct path to my runtime DLLs, which is pretty annoying. (Or I copy them over to CWD and risk using the wrong versions after switching compilers. Or I link statically, which I can't for other reasons.)

What I am looking for is a a CMT_RUNTIMES_PATHS ideally configurable from both the cmake kits and also workspace settings, so I can extend %PATH% to include directories containing shared libraries.

[bobbrow]

Is CMT_MINGW_PATH appended to the configuration environment only?
Or is it also used for the Debug and Run environment?

Looking at the code, it should be merged into PATH for configure/build/debug/launch/ctest. (i.e. PATH = %PATH%;%CMT_MINGW_PATH%). I believe build/launch started getting it in 1.10. If you're not seeing that, please let us know.

So when I switch compilers I still have to exit VSCode and make it set the correct path to my runtime DLLs, which is pretty annoying. (Or I copy them over to CWD and risk using the wrong versions after switching compilers. Or I link statically, which I can't for other reasons.)

If this is happening, it sounds like a bug. The environment should be tied to the active Kit and I'm not currently aware of a case where the environment leaks across Kits.

[nidefawl]

Is CMT_MINGW_PATH appended to the configuration environment only?
Or is it also used for the Debug and Run environment?

Looking at the code, it should be merged into PATH for configure/build/debug/launch/ctest. (i.e. PATH = %PATH%;%CMT_MINGW_PATH%). I believe build/launch started getting it in 1.10. If you're not seeing that, please let us know.

So when I switch compilers I still have to exit VSCode and make it set the correct path to my runtime DLLs, which is pretty annoying. (Or I copy them over to CWD and risk using the wrong versions after switching compilers. Or I link statically, which I can't for other reasons.)

If this is happening, it sounds like a bug. The environment should be tied to the active Kit and I'm not currently aware of a case where the environment leaks across Kits.

I was referring to my current config, where I do not use CMT_MINGW_PATH

[ToBoMi]

If you add CMT_MINGW_PATH to the environmentVariables section of the kit, you should be able to set the path there instead of in your shell

Will try that soon.

I can't. Where do I add/set this? I do not use kits in a way I am aware of.

[Febbe]

I think the best would be, if a user could define the terminal, in which cmake should be called. Also, it would be good, to make the cmake executable configurable in the cmake kits.

Like:

  {
    "name": "Clang 16.0.4 x86_64-w64-windows-gnu (clang64) custom",
    "compilers": {
      "C": "C:\\msys64\\clang64\\bin\\clang.exe",
      "CXX": "C:\\msys64\\clang64\\bin\\clang++.exe"
    },
    "cmake": "C:\\msys64\\clang64\\bin\\cmake.exe",
    "isTrusted": true,
    "shell":"MSYS2-Clang64",
    "environmentVariables": {
      "CMT_MINGW_PATH": "C:\\msys64\\clang64\\bin",
      "PATH":"C:\\msys64\\clang64\\bin;C:\\msys64\\usr\\bin;${env:PATH}"
    }
  },

with terminal.integrated.profiles.windows defined in the settings.json:

"terminal.integrated.profiles.windows": 
        "MSYS2-Clang64": {
            "path": "C:\\msys64\\usr\\bin\\bash.exe",
            "args": [
              "--login",
              "-i"
            ],
            "env": {
              "MSYSTEM": "CLANG64",
              "CHERE_INVOKING": "1"
            }
          }
    },

[benjamin-branchware]

I second @Febbe's idea of being able to specify in which shell CMake is run. MSYS2 offers various MSYSTEMs where the environment is more or less completely configured for you, so why can't we just use that?

[Steelskin]

I made a PR to add MSYSTEM, MSYSTEM_PREFIX and edit PATH as suggested above. But really, I think the main issue here is that cmake should be invoked from within the appropriate MSYS shell rather than the standard environment. That being said, this PR does fix my issue.

[gcampbell-msft]

@Steelskin Thank you for the PR! We are admittedly slightly behind on reviewing PR's, we hope to get to this soon. Thank you for your patience.