[Development] Build system for Qt 6

[Bogdan Vatra]

Hi,

DISCLAIMER: I was one of the biggest QBS supporters!

QBS was a dream too good to be true, its main goals were:
a)  a simple sintax which anyone can use
b) no extrenal dependeincies to configure/build & deploy your apps
c)  designed with tooling in mind: 
   c.1) imagine a world where you can manage almost everything in your project 
from IDE but also from your text editor.
  c.2) back then, none of the existing build system could deliver enough 
information to IDEs to enable prefect code completion (e.g. include paths, 
defines, compiler flags, etc.)
d) last but not least a clean and easily maintainable code base that can be 
used for the next decade(s).

Now let's see what QBS achived from all of these goals:
a) Checked, with minor things that we can leave with (the base.concat things I 
never undersood it). 
b) We can say checked.
c.1) Nope, not really. Besides that you can add files, you can't manage no 
other things. Here CMake is better, because it exposes all its properties in a 
IDE friendly way.
c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I 
found some problems, see how QBS developers treat them here: https://
bugreports.qt.io/browse/QBS-902 . That was the moment when I started to have 
doubts :).
d) While c.1 and c.2 can be fixed with some effort, here we have bigger 
problems:
  - Instread to port QBS to QML JS in the first second when QtScript was 
deprecated, they fork it! I know that back then QML JS needed some love, but 
instead to collaborate with QML JS folks they decided keep using QtScript! 
IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it and 
kept using QtScript!
 - Even more, they found a few problem also in QML parser, and guess what, 
they forked also QML!

To fix d) a large part of QBS must be reorganized/rewritten, so, IMHO this 
project is quite DEAD, because I don't believe the community will rewrite 
those parts.

Looking at these facts, I think TQC decission is not that bad and if they want 
to start working on Qt6 soon, they had to choose a build system now, and sadly 
cmake was the only choice...

Cheers,
BogDan.

[1] https://github.com/bog-dan-ro/kdevelop


În ziua de marți, 30 octombrie 2018, la 11:00:18 EET, Christian Gagneraud a 
scris:
> On Tue, 30 Oct 2018 at 01:17, Lars Knoll <lars.knoll at qt.io> wrote:
> > Hi all,
> 
> Hi Lars,
> 
> Playing the devil's advocate here.
> 
> May I ask: Which democratic/meritocratic  process was used to take
> this decision?
> I do understand that the QtC is the Qbs instigator/maintainer, so
> nobody can blame you for pulling the plug off and adjusting resources
> allocation.
> 
> Who/when/where was the decision of switching to CMake taken?
> Any trace record? A vote, a ballot, something? I havent's hear of any
> "Qt Project" event/announcement recently.
> So far i've seen some broad (but useful) un-authoritative requirements
> from Thiago,
> followed by a lengthy (endless) discussion, and suddenly your email
> that seems to announce the result of the "election".
> When did the election happened?
> 
> So some claims that build systems are no "The Qt Company" business,
> yet you're about to take the road of having to bend a dinosaur (CMake,
> that's a personal opinion) to suit your modern requirements.
> Are you planning to have Qt employees fix CMake?
> 
> Then why spend energy/money to fix something that is broken by design?
> (Again, that is a personal opinion, if needed to say)
> 
> No conspiracy here, but i have a few more questions (not related, in
> no particular order)
> - Did Jake left the QtC due to your early decision to drop qbs? ( I
> personally do think that the decision was taken long time ago)
> - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt
> Script? - Any track record that Qbs was not fit for the job? (Please no "we
> can't build Qt with it", as you cannot build Qt with anything but
> qmake right now)
> 
> Sincerely,
> Chris