Vscode-cpptools: can we set includePath in c_cpp_properties.json globally?

[abc100m]

I would like to set includePath globally, not set it in every folder/project.
can we make this config file available in settings.json?

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": ["/usr/include"],
            "browse" : {
                "limitSymbolsToIncludedHeaders" : true,
                "databaseFilename" : ""
            }
        },
        {
            "name": "Linux",
            "includePath": ["/usr/include"],
            "browse" : {
                "limitSymbolsToIncludedHeaders" : true,
                "databaseFilename" : ""
            }
        },
        {
            "name": "Win32",
            "includePath": ["c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include"],
            "browse" : {
                "limitSymbolsToIncludedHeaders" : true,
                "databaseFilename" : ""
            }
        }
    ]
}

[BillDenton]

This would also be very useful for me as whole my projects/folders use the same settings.

[sean-mcmanus]

I agree. We'll consider adding that later.

[BillDenton]

I got around the problem by create a common config, with symbolic links to it in each project/folders .vscode directory. However, it would still be better if the settings where in settings.json. Like a lot of other extensions shouldn't the settings be in the standard settings.json. That way they could be set globally or locally as required. It would also remove one settings file.

[Gruntfuggly]

Surely the simplest way to address this would be to look for the c_cpp_properties.json file in the user settings folder if it isn't found for the workspace?

[luni3359]

Right now I just copy-paste it into every project, it's a bit annoying and it wouldn't be a bad idea to have this.

[hb9tst]

Same issue for me, sometimes I need to update the settings for particular projects, but in most cases they are the same for all of them.

[Alex031544]

Hi, same issue here. It would be very comfortable if the search paths can be defined globally. Search paths depending on the OS set up and can be different. So it is not nice to have this inside the git managed project folders.

It would be really nice if you can find a way to bring this configuration file into /home/user/.vscode/*

Thanks

[seanchann]

same issue for me. it should be work together with user custom library.

[horvay]

What I do right now is create a VisualCode folder somewhere, and put my task, settings, cpp config in there.

Then I create a whatever.code-workspace file that looks something like this:

{
    "id": "1503499542888",
    "folders": [
        "file:///c:/w/pa/Lumberyard/1.9.0.1/dev/VisualCode",
        "file:///c:/w/pa/Lumberyard/1.9.0.1/dev/Principia",
        "file:///c:/w/pa/Lumberyard/1.9.0.1/dev/TutorialSeries",
        "file:///c:/w/pa/Lumberyard/1.9.0.1/dev/Code",
        "file:///c:/w/pa/Lumberyard/1.9.0.1/dev/Gems/PhysicsWrapper"

    ]
}

Then open that .code-workspace file with vscode (the file extension should be associated to vscode).

This creates a visual code setup that looks like this:

Now all my separate projects (Principia,TutorialSeries, PhysicsWrapper) all use the same cpp config and task.

Each project has it's own launch.json file in it though, and my debugger launch options look like this:

You can probably have the tasks.json in each separate project too.

[bobbrow]

@horvay it looks like you are taking advantage of the fact that we haven't added support for multi-root workspaces in our extension yet and only the first folder is parsed. When we do add support for it, what you've posted will no longer work.

We are still considering merging c_cpp_properties.json into settings.json.

[horvay]

Will it break? Or merely be not necessary? Do you know a ballpark for when you all plan to release support for multi-root?

[bobbrow]

Nothing will "break" per-se, but when we add the support, we will load the c_cpp_properties.json from each folder you've opened and apply it to the files in that folder instead of just loading the c_cpp_properties.json from the first folder and applying that to everything.

We plan to start looking into this more next month, with a possibility for us to release in October if everything goes as planned. The VS Code team has been investigating some of our suggestions and just sent me some sample code with a new API this morning that looks promising.

[horvay]

Awesome! I deleted the cpp configs from the other folders for now. But I'll definitely go back to having local specific ones after that release.

Thanks for all the work you all put into this!

[sweenish]

I do believe that this has not been implemented yet.

I'm on Windows and it is absolutely infuriating to have to add the same thing to the c_cpp_properties.json every time I start a new project.

Same goes for me on Fedora, at least there it knows where to look and I can add the necessary paths (plural) with a couple clicks. Windows doesn't afford that option.

I currently have Visual Studio Community installed, providing the necessary paths. I will be experimenting with just the build tools on my laptop, but this inability to set the *.json globally is a constant thorn in my side.

[yepher]

Here is my use-case which looks a little different from others. I am working on a Mac but the files I am editing are remote on a Linux box. To do this I am using rcode and ssh port forwarding. This is my ~/.ssh/config file:

Host mydev1
    HostName  dev1.someHostName
    User devuser
    ForwardAgent yes
    RemoteForward 52698 127.0.0.1:52698
    RemoteForward 6666 127.0.0.1:6666

Port 52698 is for rcode and port 6666 is my gdbserver.

So I would like to have a global includePath configuration so vscode (InteliSense) will use the local header files etc if I don't have the remote file opened already.

If I set an environment variables C_INCLUDE_PATH (for C header files) or CPLUS_INCLUDE_PATH (for C++ header files) will vscode pick that up?

As Ciro mentioned, CPATH will set the path for both C and C++. will vscode look at that for my include paths?

Doing this would be very helpful for my workflow and maybe others who need to do similar.

[bobbrow]

We do support environment variables in the includePath. We also support semicolons as a path break if you happen to use an environment variable that defines multiple paths.

You can use ${C_INCLUDE_PATH} or ${env:C_INCLUDE_PATH}. Either syntax is fine.

[yepher]

Great, then that should solve my use case. Although I just tried and it seems I have to have a directory open for that to work. In rcode case there is no way to open a directory. Instead, you must open single files.

I assume no work around for that?

[bobbrow]

Can you create and open an empty folder somewhere on your local host and still use rcode to pull in your files? The c_cpp_properties.json file has to live somewhere, and we don't currently have a mechanism that wires this up in the single file case unless a folder is open. In the future, when c_cpp_properties.json is moved into the settings, you shouldn't need this workaround.

[yepher]

Yea, I will do that. I guess my request was in the vein of a global c_cpp_properties.json maybe in ~/.vscode/c_cpp_properties.json or something like that.

Your advice has helped me a lot and is a great workaround for the issue I was having.

[bobbrow]

I guess my request was in the vein of a global c_cpp_properties.json maybe in ~/.vscode/c_cpp_properties.json or something like that

We are planning to support global configs by removing the c_cpp_properties.json file completely and moving its content to VSCode's settings file.

[JulianDavis]

Hi I'm just starting to learn C++ and trying to configure cpptools for VSCode has been very challenging but I'm up and running though, finally. And I really look forward to this feature of a global c_cpp_properties.json file.

[thejcannon]

FWIW I just fixed #314 which allows config:... replacements in c_cpp_properties.json.
That means you can stick anything you want into your user settings and use it in c_cpp_properties.json.

That's definitely easier than an environment variable.

[sean-mcmanus]

We haven't shipped the fix yet though (ETA is next week), unless you want to build/run it from the OSS, but binary that is retrieved is slightly out of date so inactive regions probably don't work (they require the binary in the 0.15.0-insiders release).

[Artalus]

So, what's the progress?

[sean-mcmanus]

@Artalus The progress for what? Global settings is scheduled for April.

[bryceschober]

My use case seems a bit different, what I want is the ability to have a shared base configuration that applies to all the others. In our basic GNU make-driven projects, I find myself adding several ${workspaceRoot}-relative include paths to exactly the same values for every configuration. If there was support for a "shared" configuration in the same file that the others overlaid, I'd be happy.

[Gruntfuggly]

@bryceschober I had a similar problem, so I knocked up an extension global-config to make it easier to copy (or link) a standard set of files - it might be useful until it's implemented properly...

[sean-mcmanus]

@bryceschober It sounds like you mean c_cpp_properties.json settings that apply to all the configs, so that each individual config would just overwrite or add to the base one. We weren't planning to add that, but it sounds like a good idea to me.

[bryceschober]

@sean-mcmanus Yes, that's exactly what I mean.

[bobbrow]

I have just posted a plan to issue #1338 that may address this issue. I encourage those on this thread to take a look and provide feedback.

[bobbrow]

A preview of this is available in the insiders build if you would like to try it out and provide feedback.

Set "C_Cpp.default.includePath" to the path you want to use globally. You can reference this in c_cpp_properties.json by using "includePath": "${default}", ... ] or simply deleting the "includePath" property from the configuration.

[bryceschober]

Wait, how does this reduce duplication between different configurations in c_cpp_properties.json shared between users? How would one specify some baseline include paths for all configurations, and then different platform-specific include paths?

[bobbrow]

Sharing between users might require the "advanced" section of the spec in #1338 which is not implemented yet. We haven't gotten enough votes from users to determine if it's worth introducing the complexity since most users are still struggling with basic configuration, so we've been focusing on solving that first.

Otherwise, you would be able to share a base set of includes across multiple platforms like this:

.vscode/settings.json

{
    "C_Cpp.default.includePath": [
        "${workspaceFolder}",
        "${workspaceFolder}/include"
    ]
}

.vscode/c_cpp_properties.json

{
    "configurations": [
        {
            "name": "linux",
            "includePath": [
                "${default}",
                "${workspaceFolder}/include/linux"
            ],
        },
        {
            "name": "osx",
            "includePath": [
                "${default}",
                "${workspaceFolder}/include/osx"
            ],
        },
        {
            "name": "win32",
            "includePath": [
                "${default}",
                "${workspaceFolder}/include/win32"
            ],
        }
    ]
}

[bryceschober]

IMO, this would be a whole lot easier for ordinary users (though I have no idea how hard it would be for you to implement):

.vscode/c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "default",
            "includePath": [
                "${workspaceFolder}",
                "${workspaceFolder}/include"
            ],
        },
        {
            "name": "linux",
            "includePath": [
                "${default}",
                "${workspaceFolder}/include/linux"
            ],
        },
        {
            "name": "osx",
            "includePath": [
                "${default}",
                "${workspaceFolder}/include/osx"
            ],
        },
        {
            "name": "win32",
            "includePath": [
                "${default}",
                "${workspaceFolder}/include/win32"
            ],
        }
    ]
}

[bobbrow]

This is one of the possibilities on the table. But it opens up a sort of inheritance graph with potential cycles, etc. It also creates partial configs that should probably not be selectable. There are a few issues with this design that we need to refine, but this is very similar to what I proposed in the "advanced" section of the spec in #1338.

[bobbrow]

For your particular scenario, however, the "advanced" scenario seems overkill. We could probably address your case more easily by adding an "environment" section or something that lets you define custom variables for your own usage:

{
    "environment":  {
        "defaultIncludes": [
            "${workspaceFolder}",
            "${workspaceFolder}/include"
        ]
    },
    "configurations": [
        {
            "name": "linux",
            "includePath": [
                "${defaultIncludes}",
                "${workspaceFolder}/include/linux"
            ],
        },
        {
            "name": "osx",
            "includePath": [
                "${defaultIncludes}",
                "${workspaceFolder}/include/osx"
            ],
        },
        {
            "name": "win32",
            "includePath": [
                "${defaultIncludes}",
                "${workspaceFolder}/include/win32"
            ],
        }
    ]
}

[bryceschober]

That looks good to me, as long as it's all in one shared configuration file and documented not-too-deeply.

[bobbrow]

This has been addressed in 0.17.0.

Also, a minor variation from the comment above, the final syntax for the custom variables uses a property called "env" instead of "environment":

{
    "env":  {
        "defaultIncludes": [
            "${workspaceFolder}",
            "${workspaceFolder}/include"
        ]
    },
    "configurations": [
        {
            "name": "linux",
            "includePath": [
                "${defaultIncludes}",
                "${workspaceFolder}/include/linux"
            ],
        },
        {
            "name": "osx",
            "includePath": [
                "${defaultIncludes}",
                "${workspaceFolder}/include/osx"
            ],
        },
        {
            "name": "win32",
            "includePath": [
                "${defaultIncludes}",
                "${workspaceFolder}/include/win32"
            ],
        }
    ]
}

[jeansordes]

Just to know, the issue seemed to have been closed buuuut I have a hard time finding how to translate to this new system. Like, for now, I have to put that file in every C/C++ project I work on, so now how can I do for having it at a global level ?

// .vscode/c_cpp_properties.json
{
    "configurations": [{
        "name": "WSL",
        "compilerPath": "/usr/bin/gcc",
        "includePath": [
            "${workspaceFolder}/**",
            "/usr/lib/gcc/x86_64-linux-gnu/5/include",
            "/usr/local/include",
            "/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed",
            "/usr/include/x86_64-linux-gnu",
            "/usr/include"
        ],
}

[bobbrow]

@eurakilon, take a look at this documentation