[Development] Future of QBS

[Eike Ziller]

> On 18. Oct 2017, at 08:35, Jake Petroules <Jake.Petroules at qt.io> wrote:
> 
> 
> 
>> On Oct 18, 2017, at 12:48 AM, Christian Gagneraud <chgans at gmail.com> wrote:
>> 
>> 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.
> 
> You're right, they are orthogonal. The Qt module files happen to be located in the qbs repository right now. The Qt module files, long term, should be located with or generated by the build of Qt itself. For the latter case, building Qt with Qbs implies that that will become the reality anyways, which is why I strongly associated the two.
> 
> Of course, we could do it *now* even when still building with qmake, but there would be no point doing things in that order. Just like there are CMake files shipped with Qt, which exist when Qt is built with qmake, and will continue to exist when it's built with Qbs.

At this point in time it probably wouldn’t make much sense to ship Qbs files with Qt itself, until Qbs stabilizes itself more and guarantees compatiblity for at least a few years. It would be highly annoying if you had to be careful which Qbs version to take for building some Qt version (and would lock your project’s build files too, if you use Qbs for them).
I suppose the same holds true for building Qt itself with Qbs (as the only option). Or any other widely used project.

> So again, we already agree - it's just a matter of how it's being phrased/explained.
> 
>> 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.
> 
> If I didn't say so before, this is entirely temporary. It will go away.
> 
> I'm not sure about the Qt Creator case being referenced here, but if you can open a bug report that would be helpful.
> 
>> 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.
> 
> Possibly. This is what I was referring to by "dynamically generate modules at runtime". By the way, Qt is not currently one module, it's several dozen.
> 
>> 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.
> 
> And right now, it isn't different. You're confusing the existence of qbs-setup-qt with some sort of fundamental hardcoded tie-in to Qt. It's simply a helper tool that fills in some module properties. In terms of the high level constructs available in the Qbs language, Qt is no more special than anything else.
> 
> And like I said before, qbs-setup-qt should probably go away eventually.
> 
>> 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.
> 
> Not necessarily. The non-Qt related things are in many ways more difficult than the Qt parts.
> 
>>> 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.
> 
> Indeed, Qbs can be used for non-Qt projects and this is the default case (unlike qmake where it must be explicitly turned OFF).
> 
> I don't understand why you think this doesn't make Qbs completely decoupled from Qt though. You're saying that Qbs isn't decoupled from Qt because if you need Qt for your project... Qt gets pulled in? That doesn't make any sense. Can you provide a more concrete example?
> 
>>> 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.
> 
> Anything in this area is something we want to address. So please so provide specific feedback for any issues you're running into.
> -- 
> Jake Petroules - jake.petroules at qt.io
> The Qt Company - Silicon Valley
> Qbs build tool evangelist - qbs.io
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B