Nothing technical here. In future videos I'm going to be using Visual Studio Code to drive CMake so I thought I'd make sure to document how you can follow al. This is a quick video to show how to quickly get a CMake project configured, built, executed, and debugged in VS Code.

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.

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.

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:

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:

Visual Studio Code Configure Cmake

• 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:

Cmake Tools Visual Studio Code

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.

Vs Code C++ Cmake

Make Visual Studio Code Work With C# Code

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).