Last week, Qt Company announced they were deprecating Qbs, and in its place would begin focusing their efforts on CMake support. It must have been a difficult call to make; a lot of time and effort has been invested into Qbs over the past 6+ years: design, implementation, support, and Qt Creator integration among others. Not to mention, any teams out there who may have invested their own time and energy into creating projects with Qbs. They now get a surprise migration project added to their plate. The general reaction on the mailing list is pretty pissed off. As for myself, I’m glad to see the project promoting CMake as their primary build system.

Today, qmake is the official, primary build tool for Qt; for applications and framework alike. The tool generates platform appropriate Makefiles, project files for IDEs, and runs tools for code generation (supporting widget ui files, meta-object classes for QObjects, and resource files). Replacing qmake has been a long time coming, there’s probably been discussion concerning it’s potential successor longer than I’ve been programming in Qt! Almost a decade ago, there was a blog post detailing the neccessary criteria for potential replacements. The main points were as follows:

  1. Avoid a “proprietary” language
  • Promote good IDE integration
  • Build projects directly
  • Support for distributed build systems
  • Support cross-compiling
  • Support pkg-config
  • Generate deployment packages / installers
  • Provide configuration of projects

First officially introduced in early 2012, Qbs was intended to be a replacement for qmake. Introduced in the wake of QML, it naturally adopted a similar declarative Javascript syntax. Thus, satisying criteria #1. Reviewing the list of criteria, Qbs satisfied the majority of them. Over the following six years the tool continued to mature, receiving regular releases alongside the Qt framework and Qt Creator IDEs. Ask the right Qt Company developer during the annual Qt World Summit, and you may have even heard that Qbs was going to be the defacto build tool for Qt 6.

Meanwhile, many projects were adopting CMake as the build tool of choice. CMake is a cross-platform build system, much like qmake. First released back in 2000, it’s an open-source project, of which KitWare is perhaps the most visible contributor. The earliest mention of Qt I can find in CMake’s blog goes way back to July 2006 for the 2.4.2 release. The occasion for this event was KDE had chosen CMake as it’s build system, a very large, complex project to support. CMake support for Qt has continued to improve over time, to the point where it’s included in the Qt Creator IDE alongside Qbs. Anecdotally, when I encounter libraries or applications built with Qt, I find they’re built with CMake far more frequently than qmake or Qbs.

When we evaluated potential build tools at my current employer back in 2013, we considered the complexity of our product, community support / adoption for the build tool, and available IDE support. It was more important for a candidate to have been battle tested by large projects, than for it to be a perfect tool. While we make extensive use of Qt in our platform, there are significant portions that are vanilla, modern C++. We did not want to force non-Qt developers to deal with the additional cognitive overload of tooling / environment configuration that was irrelevant to their work. Developers focusing on areas other than the application platform wouldn’t need the additional tooling, libraries, and licenses that come with commercial Qt development. It needed to not only support Qt, but provide reasonable integration for RTI Connext DDS, and other 3rd party libraries / frameworks. The ease of generating sources from IDL in CMake was something that impressed us early on, as demonstrated in a recent post. After a short period of R&D, it was quickly apparent that CMake gave us what we needed in a build system.

I’m pretty happy with the outcome of this bet, and I predict the Qt Project will be as well. CMake has come really far in the past five years. In particular, I’m especially proud of a build system refactor we undertook earlier this year, where adopting Modern CMake practices greatly simplified, and optimized, the development experience with our platform. Our other big dependency, RTI Connext DDS, has begun providing CMake modules out of the box, further simplifying our work. Seeing these improvements in CMake 3.0 and beyond, I suspect Qt Company realized that the community had already voted with their time, energy, and adoption of CMake. Qt Company could choose to create their own bespoke build system, or that same effort could instead be put towards continuing to push the Qt Framework forward. I’m excited to see where this change of focus leads, and look forward to building Qt without needing to bootstrap qmake.