MinGW kit does not work as detected. Redundant kit added. Some kits not generated.

[Colengms]

When I scan for kits, I get the following kits for MinGW:

  {
    "name": "GCC 10.2.0",
    "compilers": {
      "C": "C:\\msys64\\mingw64\\bin\\gcc.exe",
      "CXX": "C:\\msys64\\mingw64\\bin\\g++.exe"
    }
  },
  {
    "name": "GCC for x86_64-w64-mingw32 10.2.0",
    "compilers": {
      "C": "C:\\msys64\\mingw64\\bin\\x86_64-w64-mingw32-gcc.exe",
      "CXX": "C:\\msys64\\mingw64\\bin\\x86_64-w64-mingw32-g++.exe"
    }
  }

Issue # 1: Only one of these should have been added. A binary diff shows that these 2 (sets of) compiler binaries are identical, both targeting x64_86.

C:\msys64\mingw64\bin>g++ --version -dumpmachine
x86_64-w64-mingw32

C:\msys64\mingw64\bin>x86_64-w64-mingw32-gcc.exe -dumpmachine
x86_64-w64-mingw32

Both of these appear to have been installed by the same "mingw-w64-x86_64-gcc" package for MSYS64.

Issue # 2: The versions of gcc installed by the "gcc" and "mingw-w64-i686-gcc" packages, are not detected at all.

colen@TITAN MSYS /c
$ pacman -Qe
base 2020.05-2
cmake 3.18.4-1
filesystem 2020.10-1
gcc 10.2.0-1
git 2.29.2-1
make 4.3-1
mingw-w64-i686-gcc 10.2.0-5
mingw-w64-i686-make 4.3-1
mingw-w64-x86_64-cmake 3.18.4-1
mingw-w64-x86_64-gcc 10.2.0-5
mingw-w64-x86_64-gdb 10.1-1
mingw-w64-x86_64-make 4.3-1
mingw-w64-x86_64-ninja 1.10.1-1
ninja 1.10.1-1

"mingw-w64-i686-gcc" is installed here: C:\msys64\mingw32\bin.
"gcc" package is installed here: /usr/bin/ (aka C:\msys64\usr\bin )

Issue # 3: The detected kits don't work. Trying to use them as detected, I get:

[cmake]   The C compiler
[cmake] 
[cmake]     "C:/msys64/mingw64/bin/gcc.exe"
[cmake] 
[cmake]   is not able to compile a simple test program.

(I have not manually added any paths to my environment globally, and don't think that should be required).

Issue # 4: I could work around issue # 3 using the following:

    "preferredGenerator": {
      "name": "MinGW Makefiles"
    }

However, that causes an error: "Unable to determine what generator to use."

I can fix that issue using the following:

    "environmentVariables": {
      "PATH": "C:/msys64/mingw64/bin/"
    }

Now, I have a seemingly working MinGW kit...

Issue # 5: There is an additional issue that is now occurring in cpptools. For some reason, when we try to probe MinGW the first time, it fails to close stdout and stderr (perhaps crashes), causing cpptools to fail and give up on it. Bob suggested this might be due to setting the PATH as above and that this may override a path CMake Tools would have otherwise added. I'm not sure if this is accurate, as the issue doesn't make a lot of sense to me. The failure only occurs the first time, and subsequent attempts to call it in exactly the same way (setting the next statement) succeeds. Also, this only repro's with Debug builds of cpptools. ... Not sure there is anything CMake Tools can do about this issue, but am curious if you can confirm whether setting PATH this way would cause a problem. If I does, it's unclear to me how else to get this kit to work...

[andreeis]

Thanks Colen for opening all the new issues. I'll split this into more GitHub reports after discussing a few details.

Issue 1: The extension sees them as different files on disk, it doesn't go out of its way to decide whether they are the same. This can be a future request (probably low pri).

Issue 2: Where did you open VSCode from? From what I know, it should be opened from an MSYS/MinGW environment. When I launch VSCode from the MinGW32, I get some kits, when I launch from MinGW64 I get the 64 bit corresponding ones. I would say this is by design, you can't have all detected. Maybe I'm wrong, I'll double check and dig more. Also, if you opened previously from a different MinGW terminal, detected a number of kits, then opened later from the other bit-ness terminal and scan again, you won't lose the previously detected ones, because CMake Tools never deletes kits. Those will no run properly now from an environment where normally they wouldn't even be detected.

Issue 3: I don't reproduce, exactly these kits you mention compile for me, via build or compile active file. I'll explore more reasons for the symptom you see. Indeed, you shouldn't add anything else to the path, but I think you should launch VSCode from a MSYS-MinGW environment/terminal.

Issue 4: Before setting a preferredGenerator to the kit itself, were you having any other generator settings? cmake.preferredGenerator or cmake.generator? In the project workspace or globally? I am not reproducing this either, but we already see different things starting with issue 3 so maybe it makes sense.

Issue 5: No idea. I hope we'll fix the previous 4 issues and issue 5 won't happen anymore. Let's see where we get with the others.

[Colengms]

Issue # 1: If the installation process for a particular compiler installs multiple aliases for the same thing, it looks like a bug to the user when our detection of that installation is incorrect (two instances of the same product, with different naming conventions). It looks like other installations of MinGW exhibit the issue, as I see the same behavior with the (older?) version of MinGW that is installs into C:\MinGW by default.

Issue # 2: Cpptools does not require that you launch VS Code from a MSYS/MinGW terminal. CMake Tools probably should not either. The need to do so is not easily discoverable by users (partly because it's not required for cpptools). Perhaps it was a requirement at one time, but users kept complaining about not being able to use MinGW that cpptools now adds the path of a compiler to the env PATH whenever we need to execute it. Also, launching from the MSYS terminal does not actually address this issue. It allows the additional detection of the installation in C:\MinGW, but the instances I referred to still are not found.

Issue # 3: I disagree that it should be required that MSYS/MinGW terminal is used to launch VS Code. Cpptools does not require this. (Though, I can imagine it may be necessary if CMake itself requires it. Though, it seems like CMake Tools could add the compiler to the env path, just like cpptools does).

Issue # 4: It looks like I had the following:

    "cmake.mingwSearchDirs": [
        "C:/msys64/mingw64",
    ],

As without this, only a version of MinGW I have installed in C:\MinGW is found. IMHO, it would be better if CMake Tools checked all default locations for versions of MinGW (which vary depending on which MinGW you install. There are many. microsoft/vscode-cpptools#6536 (comment) ). Those paths would be: C:\MinGW\bin\, C:\msys64\usr\bin, C:\msys64\mingw64\bin, C:\msys64\mingw32\bin (there may be others).

[andreeis]

Thanks for your explanations. If we change the assumption that VSCode is required to be opened from MSYS then all the bullets make sense. We'll triage these scenarios and fix them. I agree that if we do this the user experience will be more solid and complete.

[Colengms]

Based on the packages listed here:
https://packages.msys2.org/package/
https://packages.msys2.org/base

These are the various different flavors of gcc that can currently be installed with MSYS2/MSYS64:

mingw-w64-i686-arm-none-eabi-gcc
mingw-w64-x86_64-arm-none-eabi-gcc
mingw-w64-i686-avr-gcc
mingw-w64-x86_64-avr-gcc
mingw-w64-i686-gcc
mingw-w64-x86_64-gcc
mingw-w64-i686-riscv64-unknown-elf-gcc
mingw-w64-x86_64-riscv64-unknown-elf-gcc
gcc
mingw-w64-cross-gcc
mingw-w64-gcc
mingw-w64-arm-none-eabi-gcc
mingw-w64-avr-gcc
mingw-w64-riscv64-unknown-elf-gcc

[github-actions]

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.

[github-actions]

This issue is now closed due to there being no activity on it for the past 14 days since being marked as 'stale-old'.