I'm using VSCode plus CMake tools extension 0.6.0.

I use "Visual Studio 14 2015" as generator.

I ran the cmake configure command.

After that I wanted to run the "CMake: Build a Target" command.

It prompted me with a text box to enter the make target.

I entered INSTALL there and hit enter.

Nothing happens. cmake isn't launched.
The box just silently closes and does nothing :(

When I choose "CMake: Install" instead,
the build for the build target INSTALL gets launched.

Why does the manual launch of a specific build target no longer work?

Not relevant for every setting entry, but would allow to write

"cmake.buildDirectory": "${workspaceRoot}/build/${buildType}"

which would substitute ${buildType} to either Debug or Release and allow to use different build trees.

One of the most useful features of editor-build integration is to enable immediate access to files with errors or warnings from the build output.

This extension doesn't seem to provide this - can it be added?

I'm getting the error Unknown CMake generator "Visual Studio 14 2015 Win64" when I add this to my settings.json file and run cmake configure:

"cmake.preferredGenerators": [
    "Visual Studio 14 2015 Win64"
]

cmake -G "Visual Studio 14 2015 Win64" works on the command line (git bash), so I'm not sure what's going on here. The cmake extension falls back to "Visual Studio 14 2015", which is wrong in this case - I need a 64bit build.

when you pass options to the cmake command line, e.g.

cmake -HD:\somefolder\myproject -BD:\somefolder\myproject\build -GVisual Studio 14 2015 -DCMAKE_BUILD_TYPE=Debug

, some of the options lack double quotes ("). They should be added

• to the -H option (to allow pathes with spaces in them)
• to the -B option (to allow pathes with spaces in them)
• to the -G option (just for readability)

, so you get

cmake -H "D:\somefolder\myproject" -B "D:\somefolder\myproject\build" -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Debug

Without correcting this, spaces in folder names for

• source code
• build products
  will not be buildable.

This issue is used to collect feedback on the experimental Target Debugging feature.

If you have tried out target debugging and find that it works and is useful for your project, add a 👍 reaction to let me know.

Any feedback would be highly appreciated.

Learn more about this feature in these docs for Target Debugging.

This issue is very similar to what was reported in siegelaaron94/atom-build-cmake's issue 16.

Issuing CMake: Clean from the menu yields

[vscode] Executing cmake command: cmake --build ./build --target clean --config Debug -- -j 6
clean: invalid option -- 'j'
usage: ninja -t clean [options] [targets]

options:
  -g     also clean files marked as ninja generator output
  -r     interpret targets as a list of rules to clean instead
[vscode] CMake exited with status 1

Running the same command in the terminal without the offending -- -j 6 option works just fine. It turns out Ninja does not need the -j flag, as it always compiles in parallel by default.

Hello,

I have { "key": "cmd+b", "command": "cmake.buildWithTarget" } in my keybindings.json file. When I hit cmd+b, I get the pop-up box asking me to enter a build target. This claims I can hit Esc to cancel. However, if I do so, it triggers a make all.

Do I have a setting wrong somewhere or is this a bug? Thanks.

Most likely an issue with the Windows line endings

parsing regex does not match the line numbers, which appear with colons instead of in parens

If I build the default target, -j 6 is correctly passed to cmake --build (6 is the default number of threads automatically detected).

If I choose any single particular target, the same happens.

EXCEPT if I pick the install target. Then the parallel build option is not passed to CMake. On my development machine install is the target I build most often, as my testing scripts use the installed versions. Am I doing it wrong or is this a bug?

Hello,
VSCode is currently giving me a warning that there is "duplicate object key" in the /settings.json. Note that this is the defaults, not my user or my workspace settings. I am not actually sure whether this exists as a real file, or is somehow generated by VSCode? If I click on the warning, I see these lines:

// The preferred CMake generator(s) to use when configuring (tried in order of listing)
"cmake.preferredGenerators": [
    "Ninja",
    "Unix Makefiles",
    "MinGW Makefiles",
    "NMake Makefiles"
],

// The path to CMake generator executable
"cmake.cmakePath": "cmake",


//-------- CMake configuration --------

// The path to CMake generator executable
"cmake.cmakePath": "cmake",

However I can't edit this 'file', so I can't remove the duplicates. Any ideas?

I see there was a discussion about that in a some request below,
hope this is okay for you that I've raised this request separately

the default template looks like

"cmake.debugConfig": {
"all": {
"request": "launch",
"cwd": "${workspaceRoot}",
"linux": {
"MIMode": "gdb"
},
"osx": {
"MIMode": "lldb"
},
"windows": {
"MIMode": "gdb"
}
}
}

it doesn't look enough clear.

1. Are the tags above the only available settings or just basic ones? exist other ones? please describe
2. can these cpptools settings can be also used ?
3. please provide a couple samples, firstly with a most useable case: run with a command line arguments

Hello!
What result of parsing compiler output should be?
Should it create items in 'Problems' pane or only make links in plain output?

Thanks!

A lot of CMake builds use a "superbuild" methodology, in which the ALL build consists of many individual targets. Often when developing such a project, you only want to build the single target you are actively working on to save time.

This can be done through the CTRL+SHFT+P menu currently, but it's clunky. I recommend:

• Adding another button similar to the Release button, which would allow the user to input the desired target
• The Build button would then show Build ([target_name]) instead of Build (all)
• The target name would be propagated to the --target argument of the CMake command line.

Additionally, it might be nice to add a setting called cmake.initialTarget which would have a similar function to cmake.InitialBuildType, but for the target setting.

I'm not sure that is a bug and even that I can reproduce this each time
but I see this from time to time, this is related with a command : "Delete Cached settings and reconfigure".

I don't specify the generator explicitly (by the way - how to do this?), and for my environment (Win10/VC) nmake is in use. however, if I'm performing the command above, VisualStudio/MSBuild generator is in use then.

I just tried to set an invalid value in my user settings:
"cmake.preferredGenerators": [ "xxxVisual Studio 14 2015"]
and did a "CMake: Configure" step.
I wanted to see if the plugin is agnostic to the contents of that variable
and just properly passes it to cmake (in case that the cmake developers
add new generators).

This led to the strange effect that

• VSCode showed me an error message that that generator is unknown
• but anyway launched a cmake "configure" step
• which fell back to using Visual Studio 14 2015 (because it probably found that installed on my machine)

That's different from what I expected the tool to do:

• it should not try to analyze that string on its own. Why should it?
• instead, it should just pass that to cmake and let that one deal with it
• if cmake finds the generator to be invalid, it should terminate with error message

Hello,
As discussed in #5, it would be great to have a way to clear the output before building. Thanks.

This is a feature request.
if it's possible , please change the running configuration ,
in case of enable_testing() is invoked, run this target under CTest/CMake

When you do a REAL clean build,
i.e., you are completely DELETING the ./build subfolder of your sourcecode,
including all of its contents AND the folder itself,
and then are using your (nice!) plugin to launch a build without first launching
a manual "CMake: configure" command, then your plugin will display an error message
"file not found: build/CMakeCache.txt".
It would be much nicer if it instead could detect that either the folder OR that file
is not present, and in that case will automatically launch a cmake configure
instead of displaying that error message.

In version 0.4.0, the current default value for the build results folder is:
"cmake.buildDirectory": "${workspaceRoot}/build"
, and for the install results folder is:
"cmake.installPrefix": null

I would like to suggest to change that to
"cmake.buildDirectory": "${workspaceRoot}-build-${buildType}"
"cmake.installPrefix": "${workspaceRoot}-install-${buildType}"
for 2 reasons:

(a) BUILD: Putting build results into the source code tree is a Bad Thing (TM). People doing so have to explicitly ignore that folder in their revision control tool (e.g. git). It is better to completely separate the build results from the input code. If somebody REALLY wants to put the build results INSIDE the source code, he/she can still do so by explicitly setting that folder in his/her user settings or workspace settings.

(b) INSTALL: Usually you will not want to "contaminate" your build machine with installation results.
The current default of "null" has that effect, i.e., when building "INSTALL", e.g. the "bin" folder of your building host machine gets filled with that build result. What you normally want is to get all the build results into a dedicated "install" folder (as suggested above), and then do more things with that,
for example create an installation package from that using e.g. CPack. After that, the installation package usually gets tested on a dedicated installation test machine, which applies that resulting package and checks if the installation works properly. You will usually not want that on your build host.

I just tried to overwrite the default setting

"cmake.configureSettings": {
"CMAKE_EXPORT_COMPILE_COMMANDS": true,
"BUILD_TESTING": true
}

by my user settings as follows:

"cmake.configureSettings": {
"HELLO": "WORLD"
}

. I did so in trying to workaround Issue #25 .

However, that did not work as expected: instead of OVERWRITING the default values,
my settings were just ADDED, so the resulting cmake command was

cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DBUILD_TESTING=TRUE -DHELLO=WORLD

instead of the expected

cmake -DHELLO=WORLD

I think that the user settings should always work overwritingly,
as that is the only possibility to correct them if they are wrong or unwanted.

My compiler write errors to stderr. parseDiagnostics looks only in stdout.

Clicking stop will not stop it. Going back to previous version.

Hello
Thanks for this nice module!

How can I pass command line parameters to CMake? I see property cmake.initialBuildType which I want to configure different build types to different keys, is it possible to map this to a keybinding? Sorry very new to visual code!

Thanks
Simon

Visual Studio Code 1.5.2
CMake Tools 0.4.1
Arch Linux

(this is not really a bug report or feature request, but just a request to clarify the question)
the tasks in vscode allow to configure "env" environment variables.
so, with your plugin, I don't use tasks anymore. that's perfect.
but I don't know how to configure all required env variables with an extension.
currently I'm using .cmd file to start vscode with a preparing those variables,.
this is mostly a PATHs, to compiler, to cmake, to llvm, etc.
I'd like to use this configuration vscode inside, as previously. for workspace specific.

could you clarify - is it possible with your extension and how?

thank you

I currently tried to change the configuration variable
"cmake.initialBuildType": "Debug"
to
"cmake.initialBuildType": "Release"
in my VSCode user settings.

However, doing that had no effect. Still "Debug" was built when doing a clean build,
i.e., first deleting the build results folder, then running CMake: configure

Expected:
The commandline supplied to cmake should have contained the option
-DCMAKE_BUILD_TYPE=Release

Seems to be relating to the way that CMake generates processes on Windows?

I just did a test build of a minimalistic cmake project,
using "Visual Studio 14 2015" as cmake generator, i.e.

"cmake.preferredGenerators": [ "Visual Studio 14 2015" ]

I noticed that I received a warning about the unused configuration setting BUILD_TESTING,
i.e., it was set on the cmake command line but never evaluated during the build.
I checked but found no documentation about that variable.
I suppose that that variable is only used by some special build backends (e.g. Ninja or similar).

However, it anyway gets set by the default option

"cmake.configureSettings": { "CMAKE_EXPORT_COMPILE_COMMANDS": true, "BUILD_TESTING": true }

I tried to customize the default setting of cmake.configureSettings by overwriting
it in my VSCode user settings, but that did not work due to #26
, so there is no way for me to get rid of the unwanted BUILD_TESTING setting currently.

Could you please fix either #26, so I can remove it from the default settings,
or drop it from the default settings?

Currently we need to manually add the search paths to c_cpp_properties.json but it would be nice if this could be done automatically based on what cmake discovers during configure.

I used VSCode plus CMake Tools 0.6.0.

They strangely pass an unwanted option -DBUILD_SHARED_LIBS=FALSE to cmake.

That's a custom, non-standard cmake option.
My build issues a warning about that that variable gets set but not read / used.

Please don't provide that option to cmake. It seems to be generator-specific (maybe Ninja?).

I use generator "Visual Studio 14 2015" instead._

Want to be able to package up a set of build options and switch between them quickly.

It should be possible for a user to not explicitly specify a make target.

Previously, this was possible in this extension by just hitting ENTER after the command
CMake: Build target ...

This no longer works in version 0.6.0. When you just hit ENTER, nothing happens.

Expected: just a default build (for example make) without specified build target should be launched.
The implicit default of "all" will be used in those cases, but that is the job of the build backend.

The VSCode extension should just invoke that build, without handing a build target to it.

Hello, I am trying out VSCode as an editor for my C++/CMake project. Thank you so much for building this plug-in, it looks really promising for my needs.

I would really like to build a specific target (install) for my project with a keyboard shortcut, or bind the 'CMake: Build Target' command to a keyboard shortcut. Could you provide some details for how to do this, or which source code files I should look in? I am failing at the step of what to write in my settings.json file, or what command to use in my keybindings.json file.

Some Linux distributions (including Fedora) use "ninja-build" as the command to invoke ninja due to a pre-existing command called ninja.

I have msys2 installed on Windows 7 64-bit.
I have the mingw-w64-x86_64-cmake package installed.
I have this in my user settings:

    "cmake.cmakePath": "C:\\msys64\\mingw64\\bin\\cmake.exe",
    "cmake.preferredGenerators": [
        "MSYS Makefiles",
        "MinGW Makefiles",
        "Unix Makefiles",
        "NMake Makefiles",
        "Ninja",
    ],

And when I try to build a project I get this:
Unknown CMake generator "MSYS Makefiles"

cmake -G shows that MSYS Makefiles is an option. And it works when invoked from MSYS or Windows terminal.

I am using embedded MCU compiler in automotive business. We use subset of C defined by MISRA standard. MISRA compatible compilers produce much more warnings than PC world compilers (gcc for example). Some things can not be made MISRA compatible like MCU register description and they reproduce lots of warnings.
In project with I am testing this extension we have 'h' file defining MCU registers and producing around 10 thousands warnings (worst case). This file is included (indirectly) in every 'c' file. Compiler produce this 10 thousands warnings when compiling each 'c' file. Our project is small, around 50 'c' files implementing only MCU drivers, and when compiling with this extension vscode hangs.
Using vscode task with problemMatcher to run cmake build works, quite slow, but no hang.

When starting up a new instance of vscode and loading a CMake project that has no build directory created, the first compilation will always fail. This seems to be caused by the plug-in assuming that, in the absence of build files, the default build target is all, which doesn't exist on VS solution files. So the very first time the build tool is invoked through CMake, it fails because it is being told to build a target that does not exist.

Once the build files are generated, the plugin automatically switches the build target to ALL_BUILD, so subsequent compiles will work fine.

(Side-note: despite my steady stream of issue reports, I have to give a giant thumbs-up to the project. It is a tremendous life-saver for development on Windows. Thanks!)

I would like to be able to define the no. of parallel jobs (i.e. -j) for CTest only.

My unit tests don't finish, if I run them in parallel, nevertheless for building I would like to have parallel jobs.

So "cmake.parallelJobs" doens't offer the required granularity for me.

Next version of CMake (3.7) will feature cmake-server, intended to support tools that wish to ask CMake for more information about a project. Perfect!

On my test machine, the default setting
"cmake.initialBuildType": "Debug"
is unchanged, i.e., not overwritten by a user or workspace setting.

I do a clean "cmake configure" step of our project.

After that, the persisted workspace file .vscode/.cmaketools.json contains the invalid setting
{"selectedBuildType":"None"}
. Expected is:
{"selectedBuildType":"Debug"}
I guess that your implementation is as follows:

• initialize that file with "None"
• launch "cmake configure" step
• if that returns with errorcode 0, i.e. "ok", update that file with "Debug", otherwise leave untouched.

However, expected behaviour would be:

• initialize that file with the value of configuration variable cmake.initialBuildType
• only change the contents of file .vscode/.cmaketools.json when the user switches between the build type manually, e.g. to "Debug" or to "Release"
• do not make the contents of that file dependent on the errorcode return value of the cmake run for "configure".

Why am I asking this?
Because in the current situation, the wrong value will be present in the persisted file
if the "cmake configure" step fails. If that happens for a user, and he shuts down and restarts
VSCode (for example when leaving work in the evening and coming back the next morning),
and does not remember that the "configure" step failed, then a build will be launched for
build variant "None" instead of "Debug", producing a completely different build result.

the deprecation message for cmake.initialBuildType contains the typo
"cmake.intiialBuildType"

My CMakeLists scripts use the install directive to group all necessary DLLs and executables in the same folder, ready for deployment.
I also need this to run my product (project with exe and multiple dlls) as windows won't find the dlls in the build tree.
Install command in vscode along with ${cmake.installPrefix} setting would be very handy.

When building a project through cmake, vscode-cmake-tools will throw up a warning through the vscode UI if the build fails.

This warning seems unnecessary and persists in the UI until closed, plus it usually obscures the editor tab area, making keyboard-only operation difficult. It would be nice to get a config option to suppress this UI warning.

Currently, cmake is invoked from the current working directory of VS Code, which is on my platform (windows) the C:\Program Files... directory.

This bears subtle problems: When trying to build with MSYS2 or Cygwin, the argument to cmake --build <directory> --target ... uses backslashes as subdirectory delimiters. That of course doesn't work with MSYS2/Cygwin.
Running cmake from within the build directory makes the explicit definition of the build directory as argument redundant, meaning a cmake --build . --target ... (note the dot) would be a portable solution.

I've pretty much no experience with typescript, but giving the child_process.spawn a third argument with key 'cwd' might do the trick.

On my system, pressing F7 to build will cause the build to quickly fill up all available RAM as well as use up all of my CPU power, leaving my system almost completely unresponsive until the build completes.

This seems to be because it calls make -j8, even though I only have a 6-core processor.

It would be very helpful if it defaulted to a thread count of num_cpus - 1 instead (to leave one CPU free for editing), and allowed configuring a custom thread count for the "make" process.

The default target for msbuild should be ALL_BUILD, not all.