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

Andrew Knight andrew.knight at intopalo.com
Tue Sep 6 07:07:25 CEST 2016

On 09/06/16 03:08, Thiago Macieira wrote:
> Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight
> escreveu:
>> ** 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"
> Sounds like the way to go for qbs is to decouple it, make it a separate
> project, one that doesn't release in lockstep with Qt.

That's already the case. Apart from having a Qt dependency, and being 
somewhat influenced by Qt Creator development, it does not release in 
lockstep with either.

> That puts an extra burden in Qbs development: it has to be ahead of Qt's own
> development by at least two releases. Building a library should not require a
> change in the buildsystem tool: the tool should already support it by the time
> we get to that problem. That's unlike qmake, for which we make changes as we
> need them in Qt.

That might become a burden if Qbs development starts using new Qt 
features, but that hasn't really been an issue so far. AFAIK Qbs still 
builds against Qt 5.2.

Over the weekend we had a number of discussions about bootstrapping Qbs 
(or even removing the Qt dependency altogether). So, I think this 
requirement is already used in practice and hasn't greatly burdened the 
project. The Qbs developers are interested in it being small, fast, and 
portable more than relying on any recent innovations in Qt.


More information about the Development mailing list