[Development] syncqt.pl in C++

[Corentin]

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.knoll at qt.io> a écrit :

>
> > On 7 Mar 2017, at 21:54, Thiago Macieira <thiago.macieira at 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 at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170307/5f723514/attachment.html>