Qt build systems at QtCon 2016: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Andrew Knight's notes, from the the developer mailing list.)
 
(Adapted mark-up to better match wiki)
Line 8: Line 8:
offering in general.
offering in general.


* Updates from various departments
== Updates from various departments ==


** qmake
;qmake
- "Still undead"
* "Still undead"
- qmake parses c++ now (dependency scanner)
* qmake parses c++ now (dependency scanner)
- configure system rewrite drove some qmake changes
* configure system rewrite drove some qmake changes
-- The changes are "not much" ~1500 lines of code to parse and use  
:* The changes are "not much" ~1500 lines of code to parse and use formal configuration
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
-- These changes do not imply a commitment to qmake as Qt's permanent  
: (Kai) "The message we want to send is: qmake will be deprecated, but supported for a long time"
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
; Qbs
- Continues to be developed, mostly small incremental changes/releases
* Continues to be developed, mostly small incremental changes/releases
- Has been used to build Creator for a long time (alongside qmake).  
* Has been used to build Creator for a long time (alongside qmake). Support for building Creator with qmake might eventually be dropped.
Support for building Creator with qmake might eventually be dropped.
* A WIP branch in qtbase (wip/qbs) demonstrates that Qbs can build Qt
- A WIP branch in qtbase (wip/qbs) demonstrates that Qbs can build Qt


** CMake
; CMake
- (Tobias) Cmake is the "worst" system in Qt Creator because CMake  
: (Tobias) Cmake is the "worst" system in Qt Creator because CMake doesn't give enough feedback to the IDE.
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.
  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%


* Quick survey: which build system do you use (raise of hands by ~40 people)
== What should we use to build Qt in the future (qmake, Qbs, CMake)? ==
- CMake ~70%
- qmake ~20%
- Qbs ~10%


;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"


* What should we use to build Qt in the future (qmake, Qbs, CMake)?
; 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.


** Pro Qbs:
; General comments:
- (Kai) "We can do better than CMake"
* Do we really need to care what "outsiders" think of what we use in Qt?
- (Kai) "having our own build system is also about making a more "out of
:* Yes, because it is a statement about what tool is good for Qt development.
the box" experience for our users. Qt is more than a C++ library; we
::: (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"
need to ship a good-quality build tool"
:* Yes, because it is a statement about what tool is supported by Qt, and we don't want that tool to go away.
- (Rich/Stephen) Qbs might be better at doing host tools and  
::: (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
cross-compiled builds than CMake
::: (David) "Either something changes, or it dies"
- Qbs doesn't have an intermediate step (i.e. makefile generation).  
:* No, because Qt should support all major build systems anyway
Makefile generation has disadvantages for incremental builds and
* Does Qbs support dependency tracking like CMake does
dependency tracking
:* Answer: Yes
-- (Ossi) "acompletely accurate build dependency tracking system with a  
: (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"
meta build system is very expensive"
: (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."


** Pro CMake:
; General sentiment
- Much larger user base than Qbs, leading to possibly more contributions
: As long as Qbs looks like a part of Qt, it is perceived as a Qt product, and is less attractive to external users.
-- (Stephen) Most people (in this room) use CMake.
: 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"
- 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:
; Summary
- Do we really need to care what "outsiders" think of what we use in Qt?
: We are thinking about switching build systems. We don't know what to do yet, but we can't decide it here.
-- 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:
; Further notes on the switch
- As long as Qbs looks like a part of Qt, it is perceived as a Qt
: Bootstrapping Qbs is required before we can really move forward.
product, and is less attractive to external users.
:* Solving this problem isn't rocket science (Ossi), it's just not a priority.
- Yet, there remains a conflict: "if Qt doesn't use it, I don't want to
:* Linux distro maintainers might be more compelled to put a static-built Qbs in their bootstrap if Qbs is seen as a core tool
use it" vs. "if it's not outside of Qt, I don't want to use it"
: (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"
** 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"

Revision as of 14:04, 12 September 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"