CMake-Based Qt Creator Snapshots
July 13, 2020 by Eike Ziller | Comments
About a year ago we started porting the build system that we use for building Qt Creator itself from qmake to CMake. Nowadays we are in the state that many Qt Creator developers use CMake for building Qt Creator for their daily work, but the official packages are still based on the qmake build.
CMake-Based Snapshots
We proudly present you Qt Creator snapshots that were built with CMake:
https://download.qt.io/snapshots/qtcreator_cmake/
The goal of these snapshots is that they will replace the official, qmake-based packages at some point. So we want to encourage you to download, install and test them, so we can fix any breakages compared to the packages built with qmake. Please use our bugtracker for reporting issues as usual, using the component "Building Qt Creator", and the label "cmake_build".
Known Issues
Before creating a new bug report, please check our list of known issues in JIRA:
https://bugreports.qt.io/issues/?filter=22320
The biggest difference between the CMake-based packages and the official, qmake-based builds is that they do not ship Qbs. Qbs currently cannot be built with CMake. QTCREATORBUG-23905 discusses the options that we have. If you install Qbs through other means you should still be able to work with Qbs projects in Qt Creator, of course. Just point it to your Qbs executable in Options > Qbs.
Building Qt Creator with CMake
If you are building Qt Creator yourself, you should also check out switching to the CMake build. Best is if you use the "4.13" or "master" branches. Qt Creator requires at least CMake 3.10 and Qt 5.14, and LLVM 10 for the Clang code model. You point the CMAKE_PREFIX_PATH to your Qt installation and LLVM, and specify a CMAKE_BUILD_TYPE. I recommend using Ninja over other build tools, but make, nmake or JOM work, too. For example on Linux or macOS:
cd qtcreator-src
mkdir build
cd build
cmake -D"CMAKE_PREFIX_PATH=/path/to/qt;/path/to/llvm" -DCMAKE_BUILD_TYPE=Debug -G Ninja ..
cmake --build .
If you want to mimick what the packaging builds do, you can also use the build script at "scripts/build.py". That provides nice command line arguments for various build options, but might not be as suitable if you intend to develop Qt Creator itself.
Blog Topics:
Comments
Subscribe to our newsletter
Subscribe Newsletter
Try Qt 6.8 Now!
Download the latest release here: www.qt.io/download.
Qt 6.8 release focuses on technology trends like spatial computing & XR, complex data visualization in 2D & 3D, and ARM-based development for desktop.
We're Hiring
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.
Hello! Since you finally managed to build QtCreator with cmake you are able now to clarify some things - how does it feel compared to qmake? Does it offer an apparent build speed boost or does it reduce the time spent on coding build scripts? Does it simplify these scripts or maybe there are much fewer LOCs in them now? Is there any noticeable advantage?
Some personal opinion:
Fewer LOC? Not really if at all. Most of the build scripts was and is big lists of source files. And the rest is difficult to compare.
Speed boost? I don't have a direct comparison, and it much depends on the generator you use with CMake.
What I personally think are advantages of switching to CMake:
Better dependency tracking when something changes, e.g. if you change something in a build file, or in the configuration, then CMake usually manages. With qmake you often have to scrap you build directory and rebuild.
Includes a configuration system. qmake simply doesn't have one. Detects dependencies, shows summaries, can define custom options that are at least somewhat toolable (ccmake, config UI in Qt Creator, etc). For example we've added options for turning off building individual plugins and tools (without dependency tracking though). Changing the used compiler is easy, compared to qmake with its fixed mkspecs. The configuration system is a really big plus. You directly see in the configure step if LLVM was not found and a build would exclude the ClangCodeModel, just to name an example.
The CMake language is weird, but e.g. actually allows you to create shared functions in a usable way. Targets have properties, and depending on a target adds linker flags and include paths and whatever else is needed. With qmake you have to invent .pri files like our _dependencies.pri.
Otherwise there is the pure power of a widely used tool: Integrating external libraries is often easier, because they often come with corresponding CMake configuration files.
There is probaby more to be said, both good and bad.
That's one thing that I hate: list of files in. I already have all my files gathered in a folder. Why do I need to list them again in the project file / cmake file? Visual Studio is doing this stupid thing (among other stupid things). QtCreator is doing the same with qmake. Take a look how well Eclipse managed build handle it. If you want a file to be a part of your project just create it in the folder and voila. You're done.
I recently played around with Eclipse CMake project and after some searching I found how to create a wildcard rule. They discourage it in their docs but I find it the best way to define your files - just build everything.
Because sometimes you have files in the folder you don't want to be part of the project. However, you can:
The problem with using wildcards is the build system is that it is expensive to properly track dependencies then.
That is, for incremental builds, to detect whether a new file was created or deleted, the build system would have to stat all directories; this is an additional runtime cost that is avoided if you explicitly tell the build system about the files that are part of the project.