Vscode-cpptools: Include path for WSL

Created on 23 Oct 2018  Â·  5Comments  Â·  Source: microsoft/vscode-cpptools

Type: LanguageService

Describe the bug

  • OS and Version: Windows 10 64-bit, Windows Subsystem for Linux Ubuntu 18.04
  • VS Code Version: 1.28.1
  • C/C++ Extension Version: 0.19.0

First of all - sorry for the newbie question.

I am working on a C++ project in Windows Subsystem for Linux and one of the dependencies is the stdlib.h. I found it in /usr/include/c++/7.

However, when I only have "/usr/include/**" in my includePath the IntelliSense couldn't find it and says cannot open source file "stdlib.h" (dependency of "libmesh/libmesh.h"). I'd have to put "/usr/include/c++/7" in order to have the IntelliSense to find the file. I thought the wild card is including all its subfolders - could anyone please help explain a bit where I did wrong?

Thank you,
Shawn

Language Service question

All 5 comments

The most important thing to do is set the compilerPath in c_cpp_properties.json. If you do that, you won't need to manually set the system include paths and defines.

https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/Windows%20Subsystem%20for%20Linux.md

@bobbrow Thank you for your prompt response! Sorry for not explaining clearly - when I said includePath in my original post I did mean in the c_cpp_properties.json. Below is my entire json file:

{
    "configurations": [
        {
            "name": "WSL",
            "includePath": [
                "${workspaceFolder}/**",
                "/mnt/e/libmesh/with_vtk/include/**",
                "/usr/include/**",
                "/home/shwang/deal.ii-candi/petsc-3.7.6/include/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],            
            "windowsSdkVersion": "10.0.17134.0",
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "gcc-x64"
        }
    ],
    "version": 4
}

Shawn

Two things:

  1. It looks like you're using C++, did you try /usr/bin/g++ as the compiler?
  2. Did you try removing /usr/include/** from the includePath after setting the compilerPath? The extension should take care of this for you. We might not have a guard in place against recursive includes on the system folders, and if you include system paths in the wrong order, you can get cryptic errors like this.

Ah I see! Thank you so much. Sorry that my package (libmesh) has a weird
convention of naming c++ files as ".C" files. Once I change it to ".cc"
and the compiler to g++, the problem is gone.

Interestingly, when I added

{
    "folders": [
        {
            "path": "."
        }
    ],
    "settings": {
        "files.associations": {
            "*.C": "cpp"
        }
    }
}

to my workplace settings, the error still remains (although they were gone if I rename my file to *.cc); then I restart my VS Code and everything is correct!

Thanks a lot @bobbrow for your help! I really appreciate it.

Best,
Shawn

On Tue, Oct 23, 2018 at 10:37 AM Bob Brown notifications@github.com wrote:

Two things:

  1. It looks like you're using C++, did you try /usr/bin/g++ as the
    compiler?
  2. Did you try removing /usr/include/** from the includePath after
    setting the compilerPath? The extension should take care of this for you.
    We might not have a guard in place against recursive includes on the system
    folders, and if you include system paths in the wrong order, you can get
    cryptic errors like this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode-cpptools/issues/2705#issuecomment-432344810,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADUQ7d1KNHJ3stnqVsQK45Ga4j2YZv0uks5un1PSgaJpZM4X2Cbe
.

--
Yuxiang "Shawn" Wang, PhD
[email protected]
+1 (434) 284-0836

VS Code doesn't recognize case-sensitive file associations, so this is something our extension needs to patch internally. We're tracking that with #2558.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

arl picture arl  Â·  3Comments

wdc596933938 picture wdc596933938  Â·  3Comments

montery8 picture montery8  Â·  3Comments

peterwoods1 picture peterwoods1  Â·  3Comments

chrisckc picture chrisckc  Â·  3Comments