On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote:
> on top of that there are long-term savings to be made from increased
> productivity (which several posters to this thread have confirmed or
> implied). that alone won't offset the cost vs. using cmake (it would vs.
> developing and using qmake), but it's not negligible.

Speaking specifically about things _other than Qt_ (this does not really apply 
to Qt - though perhaps it does a little):

I can't really judge any of these savings as I never really had the opportunity 
to try qbs (and this is coming from me - someone who deliberately tries to 
experiment with almost every new, strange thing there is out there).

I think that qbs's worst enemy was that the "competition" of everything else in 
the space was good _enough_ (yep, even qmake, warts and all). Build systems, 
from the perspective of the people using them to build other things, are not a 
tangible part of the deliverable product you make money off of. They are a tool 
that _enable_ you to produce such a product.

Any effort that goes into changing that tooling takes effort away from other 
areas that more directly make money - and that effort requires justification. 
From my personal experience, I have never had a compelling answer for "why 
should we port to qbs" to give that justification.

"Why should we port to a tool that very few other people are using that doesn't 
provide clearly night-and-day amazing benefits when what is available today is 
better known and works well enough"? Indeed, I'll let you know if I ever figure 
out an answer to that one.

This isn't meant to say that any one tool is perfect - of course, they're not. 
But they're good enough most of the time.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to