[Development] Future of QBS

[Jake Petroules]

> On Oct 17, 2017, at 12:17 PM, Christian Gagneraud <chgans at gmail.com> wrote:
> 
> With all due respect may I suggest that building qt with qbs is actually a trap, please don't rely on that to solve your user's problems. 
> Qt is your toolkit, not mine. You should not leak. (No offense. I'm just sharing my experience, but it seems I need to justify myself if I don't want to be labelled "what are you smoking", I'm getting really pissed off about that)

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

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.

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

> - 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. :)
-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io