[Development] syncqt.pl in C++

[Kuba Ober]

> 7 mars 2017 kl. 15:54 skrev Thiago Macieira <thiago.macieira at intel.com>:
> 
> Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore escreveu:
>>> The Qt Company has now very recently made a decision to now go and invest
>>> the man power required to turn qbs into a product we can fully support in
>>> the future. This decision comes from the fact that we see that build
>>> systems are a very integral part of the developer experience, and it's one
>>> of the areas where we see that there still is a large potential for
>>> improvement. qbs is promising to bring that improvement to us and our
>>> users.
>> ​Pretty depressing since the discussions at the developer summit seemed to
>> conclude the exact opposite.​ I wish those developers were working on
>> something more useful than a new wheel.
> 
> Same here, though I have also to concede that breaking the status quo (to 
> quote Jake's tweet) is sometimes a good idea. Teambuilder -- to name another 
> Trolltech project that had nothing to do with qt -- was a couple of orders of 
> magnitude better than the tools that existed at the time (distcc). Icecream/
> icecc came about only because TB wasn't open source, but every now and then I 
> miss TB2 features that icecc doesn't have. TB3 would have been even better.
> 
> Maybe qbs will be another such leapfrog. I can't fault TQtC for trying.
> 
> But as I said, I agree with Richard and I can't help but feel that the effort 
> could have been turned into making cmake even better, especially considering 
> everyone[*] (including Microsoft!) is using it.
> 
> [*] for some reason, the other project I work with (IoTivity) chose Scons. 
> Ugh...

cmake is a "build system" in the same sense as qmake is: it only generates output for the real build tool to deal with. Of this, in practice, ninja is the only tool that won't make you grow white hair waiting for it to finish. And even then, this presents an impedance mismatch between the abstract notion of a dependency as an arrow in a graph, and of the abstract nodes of this graph, and the concrete constraint of a file that make and ninja deal with organically. 

This leaves qbs and scons as the only contenders that let you use abstract dependencies and also the building themselves. I used scons a very long while ago and it was abysmally slow by design. I don't expect anything has changed there - not without a complete rearchitecting at least. So, as far as a build system that is fast and integrates a sane programming environment goes, qbs seems to be it.

The other elephant in cmake's room is that the documentation provides nowhere nearly enough information to use it productively past trivial examples or to even develop for it well. I have to constantly refer to the source of various cmake modules to figure out how to use them beyond the simplest of ways and how to work around their shortcomings. 

Reading everything published about cmake, it seems like there is no single person who has a full knowledge of how this thing was meant to be implemented and used. Thus the preferred idioms evolve, diverge and merge all the time, and judging by the code of the modules there seems to be no consensus as to how to do almost anything. Reinventing the wheel runs rampant and ad-hoc solutions that are work arounds for design shortcomings are many. That this tool is considered to be the state of the art is lamentable at best. We all know it can and should be done better.

That's my 2c from a user perspective.

Cheers, Kuba