Vscode C++ Cmake

Afternumerouspromises of how Qbs will be the Qt's default build system, The Qt Company suddenly killed it, announced that qmake is a dead man walking too, and actually Qt is switching to CMake.

1. Vscode C++ Cmake
2. Cmake With Vscode

• CMake Tools provides the native developer a full-featured, convenient, and powerful workflow for CMake-based projects in Visual Studio Code.
• The C/C extension supports Remote Development. Editing features. The C/C extension for VS Code has many features that help you write code, understand it, and navigate around in your source files. To provide the best experience, the extension needs to know where it can find each header file referenced in your code.
• Using GCC with MinGW. In this tutorial, you configure Visual Studio Code to use the GCC C compiler (g) and GDB debugger from mingw-w64 to create programs that run on Windows. After configuring VS Code, you will compile and debug a simple Hello World program in VS Code.

So I guess we should start using CMake for building Qt applications as well. Let's see then what it takes to switch from qmake to CMake with a couple of basic examples.

I also wanted to try Qt development with Visual Studio Code, and now is a good occasion for that.

How to debug a cmake/make project in VSCode? Ask Question Asked 3 years, 1 month ago. Active 1 year, 5 months ago. Viewed 12k times 5.

I tried it on Windows 10 with MSVC 2017, however it will work on other systems too.

I've never used CMake for anything before, so to get familiar with it I decided to create two very basic applications, one with Qt Widgets and another with Qt Quick.

Instead of qmake's .pro file CMake uses CMakeLists.txt. And having spent some time I've managed to create correct CMakeLists.txt files for both projects, although I can't tell that it was very straightforward.

Lots of examples from the internet didn't work and were way too complex and overloaded in general. Surprisingly, the simplest one turned out to be the one from the official Qt documentation - who would have thought, as usually it's the other way around.

Qt Widgets

Anyway, here a project file for a Qt Widgets based application:

Essential thing here is find_package() - I have no idea what black magic it uses to find Qt in my system, but it did find it despite the fact it is installed in D:programsqt (not the most common/standard installation path). Most likely it just checks the PATH system variable, because I have D:programsqt5.12.3msvc2017_64bin there.

When I tried this on Mac OS, the configure command failed, so I had to provide the path to Qt manually:

Vscode C++ Cmake

What I don't get is why do I need to set target_link_libraries() in addition to find_package(). I mean, why would I want to find some library if not to link with it?

WIN32 is an important flag if you're building a GUI application on Windows - without it the build will fail. Obviously, you don't need it on Mac OS or Linux.

Note the ${CMAKE_PROJECT_NAME} construction - that's how you use variables in CMake. So instead of writing the name of the project (qt-widgets-cmake) I just refer to the CMAKE_PROJECT_NAME variable. And of course you can define your own variables: for instance, I used my variable sources to gather all the source files for add_executable().

Qt Quick

CMake project file for a Qt Quick application is not that difficult either. However, there are some differences:

• there is no need in CMAKE_AUTOUIC as you won't be using widgets-based .ui forms;
• instead of Widgets you now need Quick and Qml modules;
• since QML files are part of resources, you need to tell CMake about that.

So here're the changes to be made in CMakeLists.txt:

The source code of both projects including CMakeLists.txt files is available here.

First, install CMake Tools extension, because it conveniently does all the work of calling CMake with the right set of arguments for configure and build tasks.

Open your project folder in Visual Studio Code, press Ctrl + Shift + P and run CMake: Configure. First time it will ask you for a kit/toolchain - what compiler should be used for building your application. On Windows that choice can look like this:

And here's the configure output:

If it's all good, run CMake: Build and you'll get your application executable in the build folder. Here's its output:

Your application is ready to run.

When I tried this on Mac OS, the configure command failed, so I had to provide the path to Qt manually:

Vscode C++ Cmake

What I don't get is why do I need to set target_link_libraries() in addition to find_package(). I mean, why would I want to find some library if not to link with it?

WIN32 is an important flag if you're building a GUI application on Windows - without it the build will fail. Obviously, you don't need it on Mac OS or Linux.

Note the ${CMAKE_PROJECT_NAME} construction - that's how you use variables in CMake. So instead of writing the name of the project (qt-widgets-cmake) I just refer to the CMAKE_PROJECT_NAME variable. And of course you can define your own variables: for instance, I used my variable sources to gather all the source files for add_executable().

Qt Quick

CMake project file for a Qt Quick application is not that difficult either. However, there are some differences:

• there is no need in CMAKE_AUTOUIC as you won't be using widgets-based .ui forms;
• instead of Widgets you now need Quick and Qml modules;
• since QML files are part of resources, you need to tell CMake about that.

So here're the changes to be made in CMakeLists.txt:

The source code of both projects including CMakeLists.txt files is available here.

First, install CMake Tools extension, because it conveniently does all the work of calling CMake with the right set of arguments for configure and build tasks.

Open your project folder in Visual Studio Code, press Ctrl + Shift + P and run CMake: Configure. First time it will ask you for a kit/toolchain - what compiler should be used for building your application. On Windows that choice can look like this:

And here's the configure output:

If it's all good, run CMake: Build and you'll get your application executable in the build folder. Here's its output:

Your application is ready to run.

Well, it turned out to be easier than I thought - to use CMake for building Qt applications, though I spent a couple of days till I made it work. But as I read in several places, making simple things with CMake is simple, it's custom things that make everything horrible and awful - something I am yet to see.

And when it comes to Visual Studio Code as an IDE for Qt development, I have to admit - Qt Creator is still better. Especially it becomes obvious when you iterate between Designer and VS Code, or constantly read the Qt documentation because auto-complete feature sucks big ass for QML at the moment (yes, even bigger one than in Qt Creator - there is simply none).

Cmake With Vscode