13

Visual Studio 2017 has built-in support for cmake projects, meaning you can just open a folder containing a CMakeLists.txt and use it. However, there doesn't seem to be a way to prevent the console window from closing after running an executable.

With a normal Visual Studio project, you can use Ctrl+F5 to run without the debugger attached. However, Ctrl+F5 did exactly the same thing as F5, that is, it ran the executable and closed the console window immediately.

Another suggestion was to set the subsystem to "console" for the application, but the cmake project has no Visual Studio project that I can set settings for.

I figured maybe I could go to the Debug and Launch Settings for my CMakeLists.txt (right click > Debug and Launch Settings > target.exe), which opened launch.vs.json. Unfortunately, I was unable to find documentation on this. By looking through the schema, though, it seemed as if I could set "noDebug": true, but this just turned off the debugger and did nothing to stop the console from closing:

{
  "version": "0.2.1",
  "defaults": {},
  "configurations": [
    {
      "type": "default",
      "project": "CMakeLists.txt",
      "projectTarget": "target.exe",
      "name": "target.exe",
      "noDebug": true
    }
  ]
}

This is driving my crazy. I can't just add a system("pause") to the main function, as I'm using a main function provided by a test framework. Furthermore, that should be completely unnecessary; Visual Studio should handle it for me.

How can I make the Visual Studio console not close after my executable finished, when my executable is from a cmake project?

I'm using Microsoft Visual Studio Community 2017, Version 15.2 (26430.16) Release

Justin
  • 24,288
  • 12
  • 92
  • 142
  • **launch.vs.json** has a `"stopOnEntry": true` which breaks at the entry to `main()`. Too bad it doesn't have something like `"stopOnExit"`... – Justin Jul 26 '17 at 05:00
  • How about building the project and then starting the built executable directly out of a console? – Scheff's Cat Jul 26 '17 at 05:47
  • @Scheff That's something that can be done, as is setting a breakpoint at the end of the main function. However, that doesn't solve this problem; Visual Studio has it built in for normal projects. I want that behavior here. – Justin Jul 26 '17 at 05:53
  • This raised my attention as you exactly describe how we usually work in VS2013 (without problems). The main difference is that VS2013 has no built-in support for CMake (except our own home-brew). Thus, we always generate projects and solution files. Properties of the projects/solutions can be easily changed (until next CMake run will override it). Do you have this option for CMake/VS2017 (i.e. ignoring the built-in support)? (I tried to google this but only found "a thousand" links that CMake is now integrated into VS2017...) – Scheff's Cat Jul 26 '17 at 05:54
  • @Scheff The built-in support runs cmake to generate projects/solutions under `%appdata%/Local/CMakeBuild//build//` , where the project files and solution are generated. Those files are not visible inside the Visual Studio application, though. – Justin Jul 26 '17 at 05:59
  • In VS2013, these are XML files which you _could_ edit in a plain text editor. I guess, it's the same for VS2017... – Scheff's Cat Jul 26 '17 at 06:01
  • If I understood you right, you _could_ run CMake outside of VS2017 and work the "old" way. – Scheff's Cat Jul 26 '17 at 06:02
  • @Scheff Yes, you can do it the old way (I see no reason why you couldn't) – Justin Jul 26 '17 at 06:02
  • Sorry, I had no imagination how the built-in support could work. As I couldn't help you, you helped me at least a bit (to solve a potential problem which I even didn't realize until today morning).. – Scheff's Cat Jul 26 '17 at 06:04
  • Related: https://developercommunity.visualstudio.com/content/problem/97664/when-running-c-cmake-project-with-ctrlf5-the-conso.html and https://developercommunity.visualstudio.com/content/problem/46678/cmake-set-subsystem-to-console.html. @Justin Did you find a workaround? – Florian Wolters Jan 31 '18 at 20:12
  • 1
    @FlorianWolters I never actually solved this; I ended up just leaving VS and using the commandline to invoke cmake. – Justin Jan 31 '18 at 20:14

2 Answers2

3

It's a bug in Visual Studio 2017 CMake support. It is resolved in VS 2019.

As a temporary workaround, add a breakpoint on application exit and run with debugging on (F5):

  1. Press Ctrl+B (New Breakpoint)
  2. Enter function name: exit
  3. Press OK

Now if you run your project (F5) the debugger will stop after main() returns.

To remove the breakpoint, go to the Breakpoints View (Ctrl+Alt+B) and delete it from there.

rustyx
  • 80,671
  • 25
  • 200
  • 267
0

Came across this situation lately, because we sometimes use stdout for debugging info in our UI applications, we needed to turn on the console window on our dev-machines, but turn it of in our CI build.

In your CMakeLists.txt must be a 'add_executable' statement, like this:

add_executable(project_name WIN32 ${your_source_files})

If you ommit the WIN32, CMake will change the subsystem to "Console", which leads Visual Studio to keep the console window open when your application exits.

NerdyMcNerd
  • 174
  • 1
  • 7
  • Are you saying that my CMakeLists.txt has `add_executable(project_name WIN32 ...)` right now, or that I should add the `WIN32`? – Justin May 02 '18 at 19:47
  • Yes, add_executable statements declare a CMake-Targets that create an executable. If that `WIN32` exists, it will be Subsystem:Windows and if you remove it, it will be Subsystem:Console. So, i tell you to remove it. – NerdyMcNerd May 02 '18 at 20:03
  • 1
    I did not pass in `WIN32` to the `add_executable` command, just the name of the executable and the *cpp* files. – Justin May 02 '18 at 20:26
  • OK, but then it should be treated like a console application. What happens if you use CMake to generate a VS- Solution and open it in Visual Studio, does the application have the subsystem Console? – NerdyMcNerd May 03 '18 at 06:13