> On Oct 17, 2017, at 9:21 AM, Christian Gagneraud <chg...@gmail.com> wrote: > > On 17/10/2017 7:52 pm, "Jake Petroules" <jake.petrou...@qt.io> wrote: > > > On Oct 16, 2017, at 3:34 PM, jeandet <alexis.jean...@member.fsf.org> wrote: > > > > I have the feeling that a Qt build system will always force the users > > to choose between another tool they know but where the Qt support might > > not be the best and a Qt focused tool with a good Qt support but they > > will have to deal with external libs and might suffer corner cases. > > Indeed, which is why Qbs aims to solve both of those problems. Excellent Qt > support and excellent non-Qt support. Choose both. > > > As Qt user I started with qmake, I enjoyed writing projects with qmake > > then I switched to CMake to make easier usage of non Qt libs and > > config. Finally I switched to Meson and won't go back to CMake. I'm not > > sure I would switch to Qbs unless it gets less Qt focused. > > You should watch my World Summit talk when it's available on YouTube. :) > > One of the key points I talked about and which is very important is that Qbs > is NOT Qt-focused. Is it meant to be a completely generic build tool which > just happens to ship with out-of-the-box Qt support. I've been working on Qbs > for 5 years and have made close to 1000 changes, and for all of those 5 years > I actually haven't worked on the Qt support very much at all. > > Well, from a qbs user POV, Qt is still a privileged component (not talking > about qbs own build dependency here). And "qbs-setup-qt" is the curlprint. > > I don't see why this is needed (in an ideal world). This is actually a qmake > backdoor into qbs. Or call it a high coupling hotspot if you wish. > Can qbs be used to build a qt dependent project without a qt profile? I don't > think so. > > Qt should be detected the same way as any other user's project dependency > (probe link and include specifics), instead qmake is used as a proxy. > > In that respect cmake (or any other build system) got it right, qbs got it > wrong. > > On Linux, qt should be detected using qbs probe and package-config, period. > > I never liked qbs profile, they are awkward to manage in CI. > > Once you have a toolchain and a Qt profile everything is cool, but if you > start from a virgin install (eg. generic docker image), things look bad. I > guess this is a distro integration problem. But "distro" is Linux specific. > Mac and windows are far beyond.
I never liked profiles either, and we have been moving away from them as a hard requirement. On macOS and Linux you can now build projects without a profile at all (there might be a bug or two with certain MSVC installations at the moment) if you don't use Qt. Getting rid of qbs-setup-qt will take some time, and we still need to find a solution to the problem of having to hardcode the list of all possible Qt modules (although when Qt itself is built with Qbs this problem may simply go away by definition). In fact you could argue right now that Qt is NOT a privileged component since it requires special additional setup to use it. But don't mistake this as a "fundamental design flaw", it's always been a temporary solution. We have top men working on it right now... top men. > > Chris > > > > > I still miss the point of making a dedicated build system instead of > > contributing to more general build systems like Meson or even CMake. > > Qbs is just as general as both of those, and in my opinion, even more so. > Please, try it out - you may be surprised! > -- > Jake Petroules - jake.petrou...@qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
