[Development] Future of QBS
chgans at gmail.com
Wed Oct 18 00:48:37 CEST 2017
On 17/10/2017 11:27 PM, Jake Petroules wrote:
> We both want to solve the same problems, but I'm not sure exactly
> what you mean here about how building Qt with Qbs is a trap and that
> we should not "leak".
From reading your comments, I had the feeling that you're thinking that
building Qt with Qbs will help having a better Qt/Qbs integration when
building the user's project.
I think it's dangerous, the 3 things are orthogonal: building Qt with
Qbs, Qbs having a build dependency on Qt, and user using Qbs to build
their Qt-dependent (or not) own projects.
Current Qt build system (qmake) leaks into Qbs via qbs-setup-qt.
QtC suffers from that as well, I wrote an email about that, when i
realised that QtC was indirectly executing the cross-compiler defined in
qmake's mkspec and found on the PATH instead of using the one defined in
the QtC kit. This is rather scary.
> My point was that the Qbs module files to describe the various Qt
> libraries must come from somewhere - either as a probe-based module
> within Qbs, an installation of Qt itself, or a combination. If we
> rely solely on probe-based modules within Qbs, then we need a way to
> dynamically generate modules at runtime (since we can't know about Qt
> modules which don't yet exist), which is currently not possible. This
> could end up being useful in the general case too, or maybe it isn't,
> but like any major architectural decision, it needs time and
Thanks for explaining, maybe this means that Qt should not be a Qbs
module. Or it should be a "container" module that gets populated by a probe.
The handling of a product dependency on, say, Qt.Widgets, should not be
different than a product dependency on boost or whatever library.
Qbs doesn't have/need a boost module.
Now I understand that Qt is more than the sum of it's libraries/modules,
there are moc, qdoc, qrc, uic, Qml, ... too. And this make the job harder.
>> We (at work) all want this, the only problem with qbs are: -
>> stability (not blaming qbs, I knew I picked up an on going effort)
>> - Qbs != Qt
> Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling
> of Qbs and Qt is a strength, and it seems like you already agree with
I agree that it would be a strength, if Qbs and Qt were not tightly coupled.
My understanding is that Qbs can be used on non Qt-dependent projects
(bare-metal or not), nice. But this doesn't make Qbs completely
decoupled from Qt, because as soon as I need Qt for my project, the
whole "q" kitchen sink get pulled in. This is not a Qbs-specific problem
>> - CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned
>> embedded Linux builds w/o relying on qmake?
>> I have hope, of all the cross-build systems I have used in the past
>> 15 years, none have been satisfactory, could qbs make a break
> Hey, positive *and* negative (but constructive) feedback is always
> welcome. :)
This was not even negative, i am not satisfied with all the build
systems I've tried so far, but it's OK, such is life! :)
What I like with Qbs is the flexibility and its structured yet dynamic
But I'm having scalability and performance issues, that's another story
that i will report on the Qbs mailing list once i'm back on my Qbs stuff.
More information about the Development