Connect c_cpp configuration with task

[sbrw]

• Ubuntu 17.10
• vscode 1.18.1
• C/C++ 0.14.2

Would it possible to connect tasks defined in tasks.json with a configuration defined in c_cpp_properties.json.

Alternatively be able to pass defines stated in c_cpp_properties.json for the active configuration into the command field of a task in tasks.json.

The aim would be to select build task depending on active configuration, just by pressing CTRL-B, or having the configurations task selected by default in the dropdown list.

Sorry for spamming the issues section, but I spent the day at work evaluating vscode in my real production environment.

[bobbrow]

The VS Code team owns the variable substitution rules for tasks.json. Environment variables are supported by both tasks.json and c_cpp_properties.json, so the only way I can think of to share data between the two files right now is via environment variables.

I don't think it would be too big of a stretch to ask the VS Code team to support substitution of settings in tasks.json. At some point in the future we plan to deprecate c_cpp_properties.json and move those settings into settings.json so if VS Code were to add this feature we would be able to supplement it in the future.

[mbodmer]

This would make vscode a viable option for not so simple c++ projects. Especially the current active build configuration should be available in tasks. It does not make a lot of sense to have different configurations in c_cpp_properties.json and then not being able to use these while building. Usually at least the build directory would be different depending on configuration. I hope this gets it into vscode soon.

[mbodmer]

This topic has already been disussed in #742, but seems still be an issue.

[bobbrow]

https://github.com/Microsoft/vscode/issues/43782

[dsanz006]

This would be a very nice feature to have. Right now, when I want to change my configuration from debug to release, I have to change it 2 times, once for the C/C++ extension IntelliSense engine and once for my build configuration.

Another possibility, which would achieve similar results, would be to have different tasks for each configuration on tasks.json, and then reference one of these tasks in C_Cpp_properties.json, depending on the active configuration. The same could apply to the different configurations in launch.json. For me this could be better, because my configuration names do not exactly match the names of my build commands. Moreover, I have different compiler flags for my debug and release configurations (such as the -g flag for debugging).

There is a similar feature already existing between the tasks.json and launch.json files: setting an "identifier" to a task in tasks.json allows to directly execute this task just before debugging the program, defining the "preLaunchTask" key.

Should I post this in #43782?

[bobbrow]

We added the ability to consume the active configuration in version 0.22.0, but forgot to update this thread. You can use ${command:cpptools.activeConfigName} to get the "name" of the active configuration for your tasks. We don't have a way to link includes and defines at this time.

[xorcus]

@bobbrow Can these commands receive arguments? Would it be feasible to have something like: ${command:cpptools.activeConfigValue(compilerPath)} and have it return the named value (here compilerPath) from the active configuration into tasks.json.

Then ${command:cpptools.activeConfigName} would simply be equivalent to ${command:cpptools.activeConfigValue(name)}.

[sean-mcmanus]

@xorcus Commands can take values when invoked via executeCommand (see https://github.com/microsoft/vscode-cpptools/pull/4893 ) and in a keybinding associated with a command, but I don't think the command(arg) syntax is supported. But if you're just interested in more activeConfig* commands, then passing args isn't needed since the arg could just be part of the name of the command. Could you file a feature request that explains why it would be useful?

[xorcus]

@sean-mcmanus Thanks for you response. What I am looking for is exactly what was described by "How to pass VSC variables from c_cpp_properties.json to a Task? #742" (linked above in a comment by @mbodmer on Feb 15, 2018) and would also be a duplicate of this issue ("Connect c_cpp configuration with task (#1285)")

I need multiple compiler configurations (e.g. x86 and x64) and related defines (first defines __MINGW32__ and the second one __MINGW64__). I need them in c_cpp_properties.json because the choice is affecting the inactive region coloring (e.g. when I use #ifdef __MINGW64__). The problem is, when I want to switch between x86 and x64, I have to do it twice. In the lower-right corner of VS Code status bar, I change the IntelliSense choice for inactive region coloring. In the lower-left corner of VS Code status bar, I change the desired launch configuration (launch.json and the tasks.json linked by id) to match what I see in the source code editor. Ideally, I should be able to make this choice just once and affect IntelliSense, the coloring, the warnings I get as I type (the red squiggly underlines, etc) from the automated background compile and also the launch configurations.

I asked the question about passing arguments to a command above as I think it would spare the extension maintainers from adding support for many individual commands and would provide read-only access to all c_cpp_properties.json at once.

I considered defining the values I need in environment variables and then refer to "env:" in all files (c_cpp_properties.json, tasks.json and launch.json) and it would be fine until I have to change the configuration. It would be inconvenient if I always had to edit the env vars with different compiler paths etc., especially when I am working on x86 and x64 solutions at the same time in parallel and switching very often. I could simplify it by defining $MINGW32_HOME and $MINGW64_HOME and then have a $MINGW_HOME defined as one of the two. Then I just need to change 32 to 64 and vice versa, which is much easier than editing the full gcc paths. Still, I prefer the nice UI drop-down list for making the choice quickly.

According to a comment by @bobbrow, the extension is going to abandon the use of c_cpp_properties.json in favor of settings.json, so all properties should become accessible using config:*. That solution is perfectly fine for me as well.

[bobbrow]

At one point I had thought that we could abandon c_cpp_properties.json in favor of settings.json, but we decided not to do this as it would cause too much migration pain for developers. c_cpp_properties.json is optional if you are able to configure your workspace with just the settings or use a build system extension that provides configurations to cpptools (e.g. CMake Tools).

[Ben-Voris]

My use case is much like that of @xorcus https://github.com/microsoft/vscode-cpptools/issues/1285#issuecomment-613270914 in that I must target multiple tool sets and would like to make the necessary changes in one place. For me, I already have a few environment variables which are used in make to control which tool set to run and are also passed as preprocessor defines.

[bobbrow]

Now that we have our own task provider, we should be able to connect these two data sources and set up the compiler command to match the active file (or the c_cpp_properties.json).

[DzmitrySafin]

Now that we have our own task provider, we should be able to connect these two data sources and set up the compiler command to match the active file (or the c_cpp_properties.json).

I'm sorry for interfering this quite old issue, but could you give a direction where and how it has been solved, please? I see that now I can get name of the active configuration with "command:cpptools.activeConfigName". Also, I can get custom values with "cpptools.activeConfigCustomVariable" (create inputs in tasks.json or launch.json and use those inputs to substitute any value). But how I can get some standard option (like compilerPath, compilerArgs or cppStandard) from the active config and use it in tasks/launch files?

[sean-mcmanus]

@DzmitrySafin It hasn't been solved. The issue is still Open.