Issue with configuration

[bobbrow]

Hi,

After working with CMake on VS 2022, it is time to check VSCode... (the real reason that I need the project on Linux too :-)) After a lot of fail with the big project, I created a one-liner to make things simple... The project compiles without any problem under VS, but fails because of missing standard header files under VSCode...

This is the error: fatal error C1083: Cannot open include file: 'iostream': No such file or directory

The project is attached as zip file for examination... CMakeProject.zip

Originally posted by @kepeter in https://github.com/microsoft/vscode-cmake-tools/discussions/2183#discussioncomment-3115320

[elahehrashedi]

Can you please run "CMake: Log Diagnostics" when the "CMakeProject.cpp" is open and share the result of the log diagnostics with us?

[kepeter]

{
  "os": "win32",
  "vscodeVersion": "1.69.2",
  "cmtVersion": "1.11.26",
  "configurations": [
    {
      "folder": "d:\\TestBed\\CMakeProject",
      "cmakeVersion": "3.23.22060601",
      "configured": true,
      "generator": "Ninja",
      "usesPresets": true,
      "compilers": {
        "C": "C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.33.31627/bin/Hostx64/x64/cl.exe",
        "CXX": "C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.33.31627/bin/Hostx64/x64/cl.exe"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "Debug",
    "buildTypesSeen": [
      "Debug"
    ],
    "requests": [
      "file:///d%3A/TestBed/CMakeProject/src/CMakeProject.cpp"
    ],
    "responses": [
      {
        "uri": "file:///d%3A/TestBed/CMakeProject/src/CMakeProject.cpp",
        "configuration": {
          "includePath": [
            "d:/testbed/cmakeproject/include"
          ],
          "defines": [],
          "compilerPath": "c:/program files/microsoft visual studio/2022/professional/vc/tools/msvc/14.33.31627/bin/hostx64/x64/cl.exe",
          "compilerArgs": [],
          "compilerFragments": [
            "-MDd",
            "-std:c++17"
          ]
        }
      }
    ],
    "partialMatches": [],
    "targetCount": 1,
    "executablesCount": 1,
    "librariesCount": 0,
    "targets": [
      {
        "name": "CMakeProject",
        "type": "EXECUTABLE"
      }
    ]
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": true
    }
  ]
}

[bobbrow]

The difference between VS and VS Code is that VS assumes the compiler is cl.exe and VS Code does not. VS will happily set the CMAKE_C|CXX_COMPILER to cl.exe automatically for you because it assumes that's the compiler you want, but in VS Code, you will need to set it explicitly because we don't assume that everyone wants to use the Visual Studio development environment to compile their code (and Ninja requires the environment to be preconfigured before running the cmake commands).

If you add this to your "base" configurationPreset, VS Code will set up the environment the way you expect.

      "cacheVariables": {
        "CMAKE_CXX_COMPILER": "cl",
        "CMAKE_C_COMPILER": "cl"
      }

We recently updated the VS 2022 CMake template project to explicitly set the CMAKE_C|CXX_COMPILER cache variables by default as well because there were a few other users who ran into the same problem as you.

[kepeter]

It of course means that I have to have a different preset for Windows and Linux... As VS Code on Linux has no problem to compile this sample whatsoever... It would be better - for me at least - to set environment variables CC/CXX... (which is also problematic as VS moves cl location on any update according to the version number)

Thank you for the explanation!

[kepeter]

With all that said - and after adding your suggestions, and adding CC/CXX environment variables... CMake DOES find cl.exe, but still the error is there...

[bobbrow]

CMake DOES find cl.exe, but still the error is there...

Can you run the C++ extension's Log Diagnostics command this time C/C++: Log Diagnostics? It looks like you updated your previous log from the CMake extension and we're sending the compiler path over. This might be an issue with the C++ extension.

[bobbrow]

Just wanted to also note that I did try this out on your attached project and am unable to reproduce the problem once the cacheVariables are added.

I understand that this results in extra presets. Unfortunately, I'm not currently able to think of a way around it right now. condition properties are not applied at the cache variable level, only the preset level. Our extension can detect several compilers on the host machine but we'd be unsure which one is the "default." Presets don't (currently) have a way to encode that you'd want a different compiler per platform in a single preset. I'll bring this up in my next meeting with Kitware.

[kepeter]

-------- Diagnostics - 21.7.2022, 9:36:02 Version: 1.10.8 Current Configuration: { "name": "Win32", "includePath": [ "${workspaceFolder}/" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE" ], "windowsSdkVersion": "10.0.22000.0", "compilerPath": "C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.33.31627/bin/Hostx64/x64/cl.exe", "cStandard": "c17", "cppStandard": "c++17", "intelliSenseMode": "windows-msvc-x64", "intelliSenseModeIsExplicit": false, "cStandardIsExplicit": false, "cppStandardIsExplicit": false, "mergeConfigurations": false, "compilerPathIsExplicit": false, "configurationProvider": "ms-vscode.cmake-tools", "browse": { "path": [ "${workspaceFolder}/" ], "limitSymbolsToIncludedHeaders": true } } Custom browse configuration: { "browsePath": [ "d:/testbed/cmakeproject/include", "d:/testbed/cmakeproject/src" ], "compilerPath": "c:/program files/microsoft visual studio/2022/professional/vc/tools/msvc/14.33.31627/bin/hostx86/x64/cl.exe", "compilerArgs": [], "compilerFragments": [ "-MDd", "-std:c++17" ] } Custom configurations: [ D:\TestBed\CMakeProject\src\CMakeProject.cpp ] { "includePath": [ "d:/testbed/cmakeproject/include" ], "defines": [], "compilerPath": "c:/program files/microsoft visual studio/2022/professional/vc/tools/msvc/14.33.31627/bin/hostx86/x64/cl.exe", "compilerArgs": [], "compilerFragments": [ "-MDd", "-std:c++17" ] } Translation Unit Mappings: [ D:\TestBed\CMakeProject\src\CMakeProject.cpp ]: D:\TestBed\CMakeProject\src\CMakeProject.cpp Translation Unit Configurations: [ D:\TestBed\CMakeProject\src\CMakeProject.cpp ]: Process ID: 19916 Memory Usage: 94 MB Compiler Path: c:/program files/microsoft visual studio/2022/professional/vc/tools/msvc/14.33.31627/bin/hostx86/x64/cl.exe Includes: D:\TESTBED\CMAKEPROJECT\INCLUDE C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\VC\TOOLS\MSVC\14.33.31627\INCLUDE C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\VC\TOOLS\MSVC\14.33.31627\ATLMFC\INCLUDE C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.22000.0\UM C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.22000.0\UCRT C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.22000.0\SHARED C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.22000.0\WINRT C:\PROGRAM FILES (X86)\WINDOWS KITS\10\INCLUDE\10.0.22000.0\CPPWINRT Standard Version: ms_c++17 IntelliSense Mode: windows-msvc-x64 Total Memory Usage: 94 MB

------- Workspace parsing diagnostics ------- Number of files discovered (not excluded): 4987

[kepeter]

CMake DOES find cl.exe, but still the error is there...

Can you run the C++ extension's Log Diagnostics command this time C/C++: Log Diagnostics? It looks like you updated your previous log from the CMake extension and we're sending the compiler path over. This might be an issue with the C++ extension.

It may be something about environment variables that went wrong, so VS Code can't find certain files? There is a list of used environment variables I can check?

[kepeter]

Just found that Visual Studio has two extra environment variables that may have something to do with my problem

EXTERNAL_INCLUDE=C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.33.31627\include;C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.33.31627\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um INCLUDE=C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.33.31627\include;C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.33.31627\ATLMFC\include;C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\VS\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\cppwinrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um

[bobbrow]

That path looks correct. It's essentially the same as mine and mine works. C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.33.31627\include

cpptools is using it according to the log, but it still can't find iostream? Did you look in that folder and see if the header is there?

[kepeter]

Yes. The files are there... I added manually the two missing environment variable (INCLUDE and EXTERNAL_INCLUDE) and now it compiles also under VS Code...

[bobbrow]

That's weird because CMake Tools should be running devcmd.bat for you automatically (it does for me with your project) and storing the INCLUDE variable to add to the build environment for you. When that fails we log an error to the OUTPUT window.

[github-actions[bot]]

This issue has been closed automatically because it's labeled as a 'question' and has not had recent activity.