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