[Development] Future of QBS

[Tobias Hunger]

Hi Jake,

take a breath, I was not even trying to attack qbs. These debates get way too emotional for my taste!

All I did was to ask to see qbs *sold* better and with more facts backing up our claims about it.

> > to use your version control picture: Are we trying to sell
> > subversion by showing how great that is compared to
> > CVS and RCS, while git is just getting introduced into
> > the market?

> Your analogy is stacked to support your (biased) argument.

Is my lack of enthusiasm for qbs making me biased towards cmake in your book? You got a strange friend-foe recognition algorithm at work there:-)

> In my (admittedly also biased) version, autotools, qmake,
> CMake, etc., are RCS, CVS, and Subversion. Qbs is git.

Linus did not compare git to CVS and RCS either, when he went to 'sell' git. He compared to monotone, and others VCSes that were state-of-the-art at the time instead.

So why don't we follow that example?

> Rhetoric like this is good for presentations and advertisements, but not very good in logic-based debates.

I have not noticed you shying away from a bit of rhetorics yet:-)

> > I am still missing a comparison of qbs and *current* build
> > system options. All I see is qbs vs. qmake and qbs vs.
> > cmake 2.x. Neither qmake nor cmake is what qbs will
> > be competing with by the time it is ready to be used in earnest.

> Please give concrete examples of how CMake 3.x is so much
> more competitive now vs 2.x before continuing with this sort
> of argument.

It's a statement, not an argument.

Qbs is always compared to cmake 2.x or qmake (or at least I do not remember seeing it compared to something more recent). I went on to say that qbs will have to compete with newer tools than qmake and cmake by the time it is ready to be used. So I think it makes sense to show how qbs compares to newer tools.

Your presentation is just the latest example doing a qbs/cmake 2.x comparison. You left out development in cmake since 2014. You even went ahead and highlighted problems with recursive makefiles (which were never used in that form in cmake) and (as far as I recall) did not mention ninja. I doubt you will win over cmake users that way: Why would they perceive your statements are relevant to how they use cmake?

> I'm also not opposed to comparing against a wider range
> of build tools,

I had asked for a different set, not a wider range. Sorry if I did not make that clear.

> but keep in mind it's more useful to compare against what's
> actually relevant to our users in the market *now* (as in what
> people are already using), rather than options that do exist but
>  no one has actually considered or used yet in the context of Qt.

You repeatedly made the claim that qbs is targeting far further than Qt. Every tool I mentioned *is* used by developers right now.

> > So far we excluded most possible build systems on the grounds
> > that they do not support the mixed host/target builds we do.
> > That requirement is going away. So we have more options now.

I am surprised you left this part uncontested:-)

> > Just to name two: Bazel promises great scalability and reliability,
> > meson claims to be simple and fast. Even CMake made a lot of
> > progress since version 2.x.

> Qbs also promises scalability and reliability and also claims to be
> simple and fast.

When I read about bazel, I do find facts that (in my mind) support the statements about scalability (builds the entire google codebase) and reliability (e.g. only pre-declared inputs/outputs are available to all processes run by bazel). The same is true for Meson (very few commands, no functions or macros, so simple, and uses ninja, so fast compared to the make-baseline).

I would like to be able to do the same for qbs. E.g. as far as I can tell the only project currently building with qbs is creator, which is a comparatively small project. You just claimed that qbs is scalable. How do you substantiate that?

Without facts we are bound to have an emotional debate, so please provide more:-)

> Apparently, stating the tagline of a product somehow means
> that product is the best choice...?

I never made that claim.

> Meson is the same age as Qbs, so you can't reasonably put
> it into the conversation, because it did not exist at the time we
> invented Qbs.

I fail to see the logic here. Qbs was also not around when cmake was started either, yet you did compare the two in your presentation.

> Do you expect us to simply give up because competition
> *exists*?

No, I expressed hope that we watch the competition and that we are aware of the strength and weaknesses of our product compared to said competition.

> They have most certainly not magically leapfrogged over us in
> the same amount of time.

At QtCS you had not yet looked into meson, so how do you know?

> Same with Bazel - released in 2015. Again, some new software
> comes around and we just give up?

How did you get from "please compare qbs to something more current than qmake" to "let's give up"?

> Sounds good, let's abandon Qt and sell Xamarin consulting services
> instead since they're better than us now. Hey Microsoft, since clang is
> simply way better than MSVC now, why don't you just stop developing
> your compiler? Absurd.

Let's wait and see: Microsoft might end up switching MSVC to be clang based:-) Who knows?

> > I would also appreciate getting some numbers to back up the claims made about qbs.

> Well, you heard what I said on Thursday. Maybe you could
> volunteer some time to help do this.

I did. I am pretty sure you quoted some of the numbers I gathered during your presentation on Thursday.

> The rest of us are already heavily booked working on features
> and doing the Qt port so it's much lower on our list of priorities
> now.

The product is in a better state than you make it sound here!

Best Regards,
Tobias