[Development] Future of QBS

Kevin Funk kevin.funk at kdab.com
Mon Oct 16 10:40:16 CEST 2017

On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote:
> On 14 October 2017 at 04:22, Jean-Michaƫl Celerier
> <jeanmichael.celerier at gmail.com> wrote:
> >> nobody is going to port Qt to CMake (if you disagree start a new thread)
> > 
> > https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8
> 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.
> 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 .
> 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.
> "Not reinventing the wheel" has to be balanced with "innovation".
> IMHO, Qbs' great potential is the "completely new approach".
> Qbs would be a failed attempt if it was "CMake&autohell in better".
> I think it's worth thinking about that, and be critical instead of
> being blind nay-sayer.
> >> a complete CMake build for Qt was already contributed upstream (quite
> >> some
> >> time ago) .. and rejected ..
> It would be interesting to know why. Oswald said "we (...) are
> strongly biased against a
> cmake-based solution", but didn't give any reason/justification (Or I
> missed it).
> Did this CMake port cover all the features provided by qmake?
> Did this CMake port provide all the configuration needed by Qt, on all
> the supported platform?
> Could the Qt CI switch to CMake then?
> And what about this "Nominating Kevin Funk for Maintainer qtbase/Build
> Systems/CMake" thread?
> Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair
> when it comes to evaluating  new build systems for Qt? or is it an
> hijack attempt, an insider infiltration?

This little 'misunderstanding' has been clarified in sub-threads already, but 
I still need to chime in here...

To paraphrase BogDan: 'What are you smoking?' 

I'm working on CMake support as part of KDAB's R&D budget on Qt project 
contributions. My contributions so far where focused on fixing the worst bugs 
in the CMake files generated by QMake so people can continue building against 
Qt's via CMake for the time being. Other contributes where feature additions 
which time and budget permit.

We don't have the incentive to turn Qt into a CMake project (as much as it'd 
make sense to *me*), as there's too much struggle within the TheQtCompany 
about which build systems to chose anyway. CMake as build system to *build* Qt 
has been proposed in the past, rejected, so at least *I* don't see a CMake 
port happening in near future either.

A CMake port would be a lot of work, as it is with porting it to QBS (cf. 
[1]), and spending time on it just to get rejected (again) is a waste of 

Thus, my time is better spent on making Qt great for *users* of Qt, i.e. a 
multitude of open source projects which successfully adopted CMake for almost 
a decade, such as software governed under the KDE umbrella.

Kevin (Funk -- certain people seem to confuse me)

[1] https://codereview.qt-project.org/#/c/201906

> Or is it pure timing coincidence, and Kevin Funk is actually a "build
> system*s* guy"?
> I have no power of decision, so i will accept any.
> Nonetheless, I think it would be a mistake to choose a build system
> over the other because "I love Xyz, Xyz is the only way. You're all
> wrong."
> Who knows, maybe the answer to "Which new build system for Qt" could
> be neither CMake, neither Qbs.
> My 2 cents,
> Chris
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Kevin Funk | kevin.funk at kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5322 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171016/519e97fa/attachment.bin>

More information about the Development mailing list