[Development] Notes on "Qt Build Systems" @ QtCon 2016

[Milian Wolff]

On Montag, 5. September 2016 14:12:23 CEST Jake Petroules wrote:
> On Sep 5, 2016, at 3:38 PM, Kevin Kofler
> <kevin.kofler at chello.at<mailto:kevin.kofler at chello.at>> wrote:
 
> - (Milian) CMakeis used by e.g. clang and it works for them
> 
> … and the whole stack of software from the KDE project, and other large
> projects.
> 
> Keep in mind that "large projects use X, therefore X is great" is a poor
> argument, because large does not necessarily mean complex. Any build tool
> is good at handling a large project (including autotools), but few are good
> at handling complex ones. Moreover, because Y uses X and it works for Y,
> does not mean X works for Z.

Currently we only know that QBS can be used for Creator, which is, quite 
frankly, far from the complexity of LLVM, all of the KDE stuff, as well as 
WebKit and the tons of other big projects that use CMake...
 
> As an incredibly simple example, make is inherently limited in that it
> cannot even represent a rule with multiple outputs (there are some
> workarounds, but they are hacky and rather limited in how they can be
> applied). And ninja is no magic bullet here either, because that still
> represents a static build graph, whereas the content of Qbs' build graph
> can actually change during the execution of the build.

Can you give an example for why we should care? This may sound flame-baity, 
but I'm really truly interested. I simply don't care about my build system, as 
long as it gets the job done without too much hassle (and yes, that is the 
case for me personally with cmake), and fast, too (which is the case with 
ninja). See also below.

> Many of you seem to not understand how complex build tools can get and just
> how simple Qbs can make problems that are incredibly challenging in other
> systems. Perhaps you should actually try Qbs before complaining about it.
> Or perhaps we simply need more/better examples to show the community the
> difference between the Rolls-Royce Trent 900 jet engine that is CMake, and
> the wet firecrackers that are CMake and qmake. Perhaps both. :)

Sure, that can be the case. But do you really think that everyone will rewrite 
their working CMake buildsystem in QBS just for the sake of it? What 
advantages does it have that would make such an effort worth it?

Also, do note that many people outside the Qt company simply don't get why 
such an effort is put into reinventing a build system, when we are in short 
supply of developers in other areas, which are arguably more important to keep 
Qt relevant. Kai mentioned competing against other languages, I wonder why one 
needs to compete against them. If Qt had proper language bindings, it would be 
used far more often...

> No one WANTS to use CMake. They use it because they HAVE to, because it's
> the only thing that exists..

I agree. But with the many years I've worked with CMake, I don't get it either 
why so many people become so passionate at hating it. Thanks to the new 
features in CMake 3 most notably, it's pretty easy to use.

> Feel free to long for the "good old days" of
> the stone age, when food was scarce, disease was rampant, and life was
> short, but we will move forward towards a better future

That is completely besides the point.

Bye
-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160905/01b2e75d/attachment.bin>