Иван Комиссаров
> 30 окт. 2018 г., в 4:34, Thiago Macieira <thiago.macie...@intel.com> > написал(а): > >> On Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote: >> Lars, I have to wonder, don't you guys miss an opportunity here? >> Qt 5 was not developed with QBS in mind. As such it probably took more >> effort than needed to fit QBS to something that was originally QMake based. >> >> At the same time you will have to fit CMake to suit the needs for Qt6. (or >> vice versa) >> >> Would it really be so much extra investment to have a build system fully >> integrated into Qt framework process that you can just make fit on the fly, >> over fiddling around the system that is overgeneralized and perhaps doesn't >> support everything as much as you'd want? > > I'm not Lars. > > But yes. > > The Qt 6 organisation won't be too different from Qt 5's, aside from the > changes that Lars and Tobias have already mentioned and that make a lot of > sense to me. So I don't see how any kind of organisation will make it easier. > > More importantly, the problem is keeping that specific buildsystem working. > If > the work isn't shared and others don't pitch in, the price to pay to keep a > Qt-only buildsystem working is too high: that's what Lars' email says. > > Finally, I'm sure any reasonable request we may have on something CMake > doesn't support yet, upstream will be willing to hear us and implement where > necessary. I quite frankly don't expect there to be much, especially since > Lars' email says that they made so much progress in so little time. > >> You've said it yourself that qbs did give good results. Maybe give it a >> chance? > > It's been given a chance. The wip/qbs branch has existed for years in qtbase. > The tool has existed for years. > > Can you name any project of moderate complexity using it? > How about Qt creator? How about commercial projects? But what I would like to ask is how about porting Qt Creator to cmake first, before porting Qt? Of course, this is not as fun as porting Qt but we can _compare_ all three build tools on that project. It is huge, uses code generation so it was a good playground for qbs. Why not use it as a playground for cmake? Then we'all have _numbers_ (speed, project files size and so on) > -- > 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