Qt build systems at QtCon 2016

We had a vibrant discussion on Qt Build Systems, hosted by Kai.

tl;dr: Lots of discussion on the merits of which build system (CMake, Qbs) should replace qmake in building Qt; lots of supporters of CMake but no volunteers to do the work, many reasons to use Qbs as well. Some related discussions about how this impacts Qt Creator and the Qt offering in general.

Updates from various departments

qmake

• "Still undead"
• qmake parses c++ now (dependency scanner)
• configure system rewrite drove some qmake changes

• The changes are "not much" ~1500 lines of code to parse and use formal configuration
• These changes do not imply a commitment to qmake as Qt's permanent build system; the real work is done in configure.json and similar JSON files and can be ported to another build system

(Kai) "The message we want to send is: qmake will be deprecated, but supported for a long time"

Qbs

• Continues to be developed, mostly small incremental changes/releases
• Has been used to build Creator for a long time (alongside qmake). Support for building Creator with qmake might eventually be dropped.
• A WIP branch in qtbase (wip/qbs) demonstrates that Qbs can build Qt

CMake

(Tobias) Cmake is the "worst" system in Qt Creator because CMake doesn't give enough feedback to the IDE.

We need first-class support for CMake in Qt Creator, though, so that is irrelevant to the discussion of which system we use to build Qt. If we build Qt with Qbs, we have to also have support in Creator. In other words, the more build systems we support, the more work Creator folks have to do to maintain it.

Quick survey: which build system do you use (raise of hands by ~40 people)

CMake

~70%

qmake

~20%

Qbs

~10%

What should we use to build Qt in the future (qmake, Qbs, CMake)?

Pro Qbs

(Kai) "We can do better than CMake"

(Kai) "having our own build system is also about making a more "out of the box" experience for our users. Qt is more than a C++ library; we need to ship a good-quality build tool"

(Rich/Stephen) Qbs might be better at doing host tools and cross-compiled builds than CMake

Qbs doesn't have an intermediate step (i.e. makefile generation). Makefile generation has disadvantages for incremental builds and dependency tracking

(Ossi) "a completely accurate build dependency tracking system with a meta build system is very expensive"

Pro CMake

• Much larger user base than Qbs, leading to possibly more contributions

(Stephen) Most people (in this room) use CMake.

• Qt is not in the business of creating a build tool
• Qbs is still not finished
• CMake is mature and widely used by Qt developers
• Using an external tool tends to benefit both projects better: the CMake community benefits from Qt's fixes to CMake, while Qt benefits from the CMake community's improvements to CMake.

(Milian) CMakeis used by e.g. clang and it works for them

• CMake comes with support for hundreds of modules; Qbs only supports Qt and pkg-config currently.

General comments

• Do we really need to care what "outsiders" think of what we use in Qt?

• Yes, because it is a statement about what tool is good for Qt development.

(Someone) "If Qbs is not used by Qt, why should I use it for my project? If Qt switches to Qbs, I will switch to it from CMake. With CMake, we don't have this problem: a lot of people are using it and it is evolving"

• Yes, because it is a statement about what tool is supported by Qt, and we don't want that tool to go away.

(Eddy) "CMake will be there even if we lose interest. By using it in Qt, we shift the burden to someone else. If qmake's future is uncertain, it will make users uncomfortable

(David) "Either something changes, or it dies"

• No, because Qt should support all major build systems anyway

• Does Qbs support dependency tracking like CMake does

• Answer: Yes

(Stephen) "In reality, rewriting Qt's build system in CMake will actually be a PITA, and will require changes to CMake to make everything better"

(Rich) "Isn't the time better spent improving CMake than build a new build system?"

There is work to do to make Qt generate better CMake files

(Andreas) "I love that Qbs is declarative. I really love how Qbs can bind dependencies and rules on how I generate artifacts"

(Someone)"The beauty of Qbs is that it is accessible and it is clear how the separation between the declarative stops and the imperative begins."

(Someone) "Qbs doesn't seem very active, and Qt doesn't use it. This scares us. CMake is the best tool we have right now, but it isn't perfect."

(Eddy) Why are we using this ancient tool? (Referring to make)

(Andreas) "Every big project ends up building their own system. Qbs is a possibility to create a new build system. If it stays in the Qt Project, less people will use it."

General sentiment

As long as Qbs looks like a part of Qt, it is perceived as a Qt product, and is less attractive to external users.

Yet, there remains a conflict: "if Qt doesn't use it, I don't want to use it" vs. "if it's not outside of Qt, I don't want to use it"

Summary

We are thinking about switching build systems. We don't know what to do yet, but we can't decide it here.

Further notes on the switch

Bootstrapping Qbs is required before we can really move forward.

• Solving this problem isn't rocket science (Ossi), it's just not a priority.
• Linux distro maintainers might be more compelled to put a static-built Qbs in their bootstrap if Qbs is seen as a core tool

(Stephen) "Go ahead and build a better build system, but make sure users can still use CMake"

(Jake) "Sometimes you have to do something different"