[Development] Notes on "Qt Build Systems" @ QtCon 2016

[Andrew Knight]

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) "acompletely 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"