[Development] Future of QBS

[Christian Gagneraud]

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

The trap:
 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.

The leak:
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
> thought.

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
> that...

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 
tho.

> 
>> - 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
>> through?
> 
> 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 
language (Qml-ish).
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.


Chris