[Development] syncqt.pl in C++
corentin.jabot at gmail.com
Tue Mar 7 23:37:56 CET 2017
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
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.knoll at qt.io> a écrit :
> > On 7 Mar 2017, at 21:54, Thiago Macieira <thiago.macieira at intel.com>
> > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore
> >>> The Qt Company has now very recently made a decision to now go and
> >>> the man power required to turn qbs into a product we can fully support
> >>> 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
> >>> 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
> >> 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
> > 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).
> > 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
> > 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 ;-)
> > But as I said, I agree with Richard and I can't help but feel that the
> > could have been turned into making cmake even better, especially
> > everyone[*] (including Microsoft!) is using it.
> > [*] for some reason, the other project I work with (IoTivity) chose
> > Ugh...
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > Software Architect - Intel Open Source Technology Center
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> Development mailing list
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development