For what it's worth, as a Qt user, QBS was, last time I checked missing some features, like non-transitive compilatuons flags, platform support and documentation.
That being said, in the past few years, I wrote some makefiles, some cmake projects. I've used WAF, qmake... QBS is the best C++ build system I've used. By far. The syntax is straightforward, logical, well thought out. For the most part, it is neither too verbose nor too little. I have managed to use it to generate intermediary files. (Maybe it still need better extensibility for that) I like that it works without stupid hardcoded paths, that it can be used to great effects for non-qt projects. Yes, it is yet another wheel, but it's a well engineered one. It fits nicely in the Qt ecosystem and if you are a little familiar with QML the learning curve is almost non existant. I've made the risky decision to use it on large-ish production software and I never regretted it. Porting existing librairies to qbs is straight forward. One could wish automatic conversion/import of cmake-base project but I have no idea if it's doable. I hardly see the need to import Qt-based libs in non-qt based projects so I don't see not using the headaches-inducing cmake as an issue. Le mar. 7 mars 2017 à 22:22, Lars Knoll <lars.kn...@qt.io> a écrit : > > > On 7 Mar 2017, at 21:54, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > > > 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. > > The discussions there were afai remember inconclusive. But the people that > do the actual work on the build system were mostly positive towards qbs. > > > > 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. > > That's what we believe. > > When we did the first version of Creator, everybody also thought we were > nuts, and that we should rather integrate with Eclipse ;-) > > Cheers, > Lars > > > > > 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... > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development