[Development] Build system for Qt 6

[Oswald Buddenhagen]

On Wed, Oct 31, 2018 at 11:16:18AM +0100, Robin Burchell wrote:
> 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.
> 
> 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.
> 
well, yes, of course. we knew that when we embarked on the journey -
build systems aren't exactly the kind of thing that many people get
excited about. mostly frustrated with. ^^

> 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.
> 
that's a perfectly fine attitude. nobody would ask you to port away
from a build system that is adequate and maintainable. except by telling
you "oh, btw, we just deprecated the build tool you're using", that is.

> "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.
> 
we/i have three target audiences in mind:
- full-time build system maintainers like myself. we feel the pain all
  day, so it's a purely selfish move to create and push something that
  actually doesn't suck.  
  part of the plan is to have a tool that isn't arcane to the degree
  that any non-trivial task must involve the maintainer to arrive at an
  acceptable quality.
- "forced switchers". a lot of projects are still on autotools, and with
  the expansion of their supported platforms beyond traditonal unix,
  they typically rewrite the build system.
- qt (creator) users who have no strong preference for their new
  projects. the idea was to have qbs as the default, to offer a *fully*
  integrated out-of-the-box experience, something that cannot possibly
  be achieved with qmake or cmake. while not 100% achieved due to
  resourcing constraints, the IDE story was central to initially
  "selling" the project internally. it's all about developer experience,
  just like qt creator, and for that matter qt itself.