[Development] Future of QBS

[Christian Gagneraud]

On 17/10/2017 9:30 pm, "Jake Petroules" <Jake.Petroules at qt.io> wrote:



> On Oct 17, 2017, at 9:21 AM, Christian Gagneraud <chgans at gmail.com> wrote:
>
> On 17/10/2017 7:52 pm, "Jake Petroules" <Jake.Petroules at qt.io> wrote:
>
> > On Oct 16, 2017, at 3:34 PM, jeandet <alexis.jeandet at 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.


With all due respect may I suggest that building qt with qbs is actually a
trap, please don't rely on that to solve your user's problems.
Qt is your toolkit, not mine. You should not leak. (No offense. I'm just
sharing my experience, but it seems I need to justify myself if I don't
want to be labelled "what are you smoking", I'm getting really pissed off
about that)

We have a couple of code bases, one is embedded Linux with Qt (UI/user
facing), others are auxiliary microcontroller and DSP running bare metal
c++.

Qbs could be used for all these projects, I don't see any big technical
difficulties.

All of these projects could benefit from qbs and the clang compilation
database plugin I wrote (yeah I can be egocentric too), everyone is asking
for auto SQA.

We (at work) all want this, the only problem with qbs are:
- stability (not blaming qbs, I knew I picked up an on going effort)
- Qbs != Qt
- CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned embedded
Linux builds w/o relying on qmake?

I have hope, of all the cross-build systems I have used in the past 15
years, none have been satisfactory, could qbs make a break through?

Chris




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.petroules at qt.io
> The Qt Company - Silicon Valley
> Qbs build tool evangelist - qbs.io
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171017/713a4c68/attachment.html>