[Development] Notes on "Qt Build Systems" @ QtCon 2016
andrew.knight at intopalo.com
Mon Sep 5 11:49:03 CEST 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
- "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
-- 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"
- 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
- (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
-- (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
--- (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
-- 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
- (Rich) "Isn't the time better spent improving CMake than build a new
- 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"
-- 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
-- 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"
More information about the Development