#Visual studio cmake plugin full#
#Visual studio cmake plugin code#

If I have to do more complex debugging, I launch Visual Studio. The fact that it supports only a single loaded. It really is quite good for C++ programming, but still vastly inferior to Visual Studio for debugging.

#Visual studio cmake plugin code#

On my personal computer I’ve resorted to using VS Code on Windows as well.

It seems to me that it would take a lo-o-o-ong time until it’s addressed. But it I doesn’t seem to be getting a lot of action. Well, at least for my not-so-trivial CMakeLists. And hence compiling a single source doesn’t work most of the time. The information for single-source targets is lost unless they are a part of a trivially defined binary target. I don’t know whether it is a reimplementation of CMake (yikes!) or they’re integrating some of CMake’s code, but they seem to have bugs. How does it get the IDE-specific metadata for the project, then? It seems to me that the developers have added a custom CMake parser to Visual Studio for that. With VS 17.4 it started configuring only once. If anything it was a motivator to optimize the CMake scripts so that configuring doesn’t take an excessive amount of time 4. This double configure was somewhat annoying but not a terrible pain. That’s why it needs the first configuration. Visual Studio can’t read ninja or CMake scripts, but it can definitely read vcxproj files. The other configuration would be the one used to actually build the project. My guess is that the first configuration is used by Visual Studio to generate hidden vcxproj files, so it could parse the targets and sources for IntelliSense and other IDE-specific stuff (like compiling a single source file). Now, I don’t have internal infomation from the dev team and I don’t know it for certain, but I’m fairly sure about it:īefore VS 17.4 a CMake project would get reconfigured two times when a CMake source is changed. Visual studio tries to invoke CMake with a source file target like a/b/, but the correct target should be something like a/b/CMakeFiles/b.dir/. What happens in these cases is that a bogus source file target name is issued and I get an error. If the sources are set at a later point with target_sources - nope. If a target is added through a macro - nope. Trying to compile a source file works if the owning binary target is defined in CMake in a trivial manner like add_executable(name src.cpp), but for anything more “complex” than this it doesn’t. It doesn’t work anymore except for the simplest of targets. That’s precisely what got broken in Visual Studio 17.4 a couple of months ago. So, Most often I use Visual Studio with CMake and the Open Folder workflow. I’m sure I even do it more often than strictly needed, but it’s a negligible overhead compared to the rest of the situations. So yeah, compiling individual sources is a second nature to me.

#Visual studio cmake plugin full#

A full build step would trigger the parallel compilation of many other sources and I would first have to wait for the slowest one to finish, and second, have my error output cluttered with the same compilation error in different contexts for every source file.

While writing the code I often compile one source file (the fastest one to compile) and deal with compilation errors there. The most common use case here is when writing code in a header which is included in several source files. You can quickly check that a source file compiles and fix (often anticipated) compilation errors without having to wait for many other sources to compile in parallel or waiting for the linker and whatnot. When writing code I find it superior to a full build in every way. The folder view is much better than the project view… anyway, Open Folder is great!Īnother thing I use all the time is Compile Single File (Ctrl-F7). Custom CMake configurations 3 are much easier to manage like this. That’s mostly because I would have to ditch ninja, but there are many reasons as well. Before that I used Code::Blocks and before that, 3000 years ago, mostly nano or SciTe 2.Įver since Visual Studio had CMake support with Open Folder I’ve been using this workflow exclusevly and I have absolutely no desire to go back to manually generated. Whenever I’m not on Windows, I use VSCode. I don’t have much experience with CLion, but I’ve been reading good things about it.

I think the modern contenders for this title would be CLion and Visual Studio Code. I think I can safely say that for the past 25 years, it has been the best IDE for C++ programming 1. One of the few products that still keep me mostly on Windows is Visual Studio.