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