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.
--
Andrew
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
