Unable to resolve includes with relative paths

[s-martin]

I have multiple VSCode workspaces side-by-side, e.g.

• MyLib1 workspace
  • src
  • data
• MyLib2 workspace
  • src
  • data
• MyApp workspace
  • src
  • data

I include headers from other workspaces in my workspace. Now I tried to resolve the includes with

includePath": ["${workspaceRoot}/../MyLib1/src",
                      "${workspaceRoot}/../MyLib2/src",
                       "/usr/include",
                       "/usr/include/linux",
                       "/usr/include/c++/4.8.5",
                       "/usr/include/c++/4.8.5/tr1",
                       "/usr/include/c++/4.8.5/x86_64-redhat-linux",
                       "/usr/local/include"],

I tried also "${workspaceRoot}/../MyLib1/src" or relative paths like "../MyLib1/src".

Unfortunately this doesn't work and no browse.VC.db is created.

I use
CentOS 7.2
VSCode 1.7.2
cpptools 0.9.2

[sean-mcmanus]

How do you know no browse.VC.db is created? Where are you looking for the file and what symptom are you getting? What happens when you change the database filename setting "databaseFilename" : "//.browse.vc.db".

[s-martin]

Ok, found files in ~/.config/Code/user/workspaceStorage/<uuid>/ms-vscode.cpptools, but the includes are still not found

[sean-mcmanus]

With the example provided, the 2nd line of the include path is missing a leading " quote. I'm not able to repro the bug. Where is the source file and what header are you trying to find? If the Microsoft.VSCode.CPP.Extension.* process is still building the browse database, then the #include finding may not work yet.

[s-martin]

@sean-mcmanus Fixed the " typo.
Source file is located in MyApp/src, headers are e.g. in MyLib1/src.

It doesn't look like the browse DB is still built, at least timestamp and size haven't changed anymore

[sean-mcmanus]

It looks like we are not expanding the ${workspaceRoot} (we internally add that path and children, but adding the ".." doesn't expand it). Replacing that by the actual path seems to fix the issue. Is that what you are seeing?

[sean-mcmanus]

A fix should be in the release after the next release. Manually expanding the ${workspaceRoot} should be a workaround.

[s-martin]

A relative path doesn't work (e.g. ../MyLib1/src).

I haven't tried absolute path, because in our setup this makes no sense, where developers could clone the repo with the workspaces to arbitrary locations.

Because the relative paths didn't work I came up with ${workspaceRoot}, which doesn't seem to work either

[s-martin]

I just confirmed that absolute paths work, however this doesn't make sense in our environment, because every developer may clone the workspaces at different locations.

I'd really appreciate, if relative paths or at least with ${workspaceRoot} would work

[sean-mcmanus]

Using a relative path works on Windows, but it doesn't work on Linux (i.e. a bug). Using ${workspaceRoot}/../MyLib2 should work in the release after the next, though.

[sean-mcmanus]

This should be fixed now.