[Development] Future of QBS

[Jake Petroules]

> On Oct 16, 2017, at 4:42 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> 
> Christian Gagneraud wrote:
>> I would resume this post as "I love CMake, CMake is the only way.
>> You're all wrong."
>> This post doesn't explain anything, doesn't gives any analysis, no
>> comparison, no argument whatsoever, nothing.
> 
> It makes one important point (and elaborates it to great lengths): developer 
> familiarity. Even if QBS were actually a lot better than CMake (something I 
> am also very sceptical about), it would still be universally hated simply 
> because it is not what developers (and distribution packagers!) know.
> 
> As a distribution packager, I am really fed up of some upstream projects 
> reinventing their own custom build systems (qmake, gyp, gn, qbs, etc.) that 
> don't work with our existing packaging boilerplate.

Keep in mind - and this is VERY important - Qbs is NOT "the Qt build system". It happens to be developed by the same people - that is all. We actually encourage people to use it for non-Qt projects.

There's actually a lot of design decisions that went into making Qbs better in ways that are not even necessarily important for Qt itself right now, but are important for ensuring that it's suitable for *any* project (and just in general having a better foundation that Qt could also benefit from in the future as well). As I said in my talk at World Summit, "Qbs should go beyond Qt".

I agree projects should not invent their own build systems. But Qbs is not "Qt's" build system, it is a new product and when I said in my talk that it's intended to compete with CMake, I didn't just mean "as a build system for Qt or for Qt based projects". ;)

>> How many people had the same reaction when clang started?
>> Nowadays, clang is actually far superior to gcc, it brought tooling
>> like we would never have dared to dream of .
> 
> Yet, Fedora packages are still built using GCC and there are no plans to 
> change that any time soon. The generated code is simply more efficient.
> 
>> Same goes with SVN vs git, now (almost) everyone have given up with SVN.
>> SVN was "CVS in better", git is a completely different approach to
>> SCM, SVN is now a zombie.
> 
> Yet, the git way to do things is not necessarily better. Revision IDs are 
> not comparable without having the absolute history. Developers can commit 
> their work locally without pushing it, encouraging intransparent 
> development. And the learning curve is a lot steeper if you are not used to 
> it yet.
> 
> That said, git nowadays has the exact same argument going for it as CMake: 
> it is what everyone is now used to.
> 
>        Kevin Kofler
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io