[QBS] Building Qt with QBS

[Oswald Buddenhagen]

On Thu, Apr 02, 2015 at 12:31:48AM +0300, Andrew Knight wrote:
> On 04/01/2015 05:58 PM, Oswald Buddenhagen wrote:
> > how much effort do you guys want to spend on improving qbs itself?
> 
> I think we would be interested in helping out, especially if it
> improves life for us and/or our customers. We are invested in QBS
> already, after all.
>
excellent.
you can/should get an overview of what the "vision" is by familiarizing
yourself with qbs' suggestion list in jira.
you know where to find us to discuss details. :)

> My crusade to git rm the .pro files from our repositories is largely
> complete...  (*evil laugh*)
> 
:D

> The nice thing about QBS is that you can do a lot with globs and
> exclusions, so it's easier to do something like this in that sense.
>
that's actually the first thing i'll criticize about the implementation.
:P
while qbs makes it easy (and reliable) to use globs, it's still a weird
thing to do, especially when you have a configurable build system -
exclusions are literally backwards.

of course, file lists with insane amounts of quotes and commas are ugly
as well, which is why https://bugreports.qt.io/browse/QBS-58 exists.

> >i'd create throw-away wip/qbs-5.5 (and later wip/qbs-dev) branches in all
> >relevant qt repos straight away. support for multiple versions can be
> >achieved the usual way: merge from -5.5 to -dev.
> 
> Yes, I guess we can pretty much follow the qmake model here, with the
> top-level project living in qtbase
>
well, the top-level project lives in qt5.git. which is not where (the
real) configure lives. which makes it immediately obvious why a
monolithic centralized configure is a flawed design.

> One thing I like about the centralized approach (i.e. putting the
> project(s) in qt5.git) is that the directory structure more easily
> take on a different shape. For example, qtbase's and qtwayland's
> platform project files could share the same hierarchy. You lose that
> with submodules. You also lose it if you are boring and follow the
> source hierarchy.
> 
i can understand how this is appealing when all you do is a buildsystem,
but for a "regular" developer (who just wants to make minimal changes
while writing actual code) this is part of the nightmare i've been
talking about.

> Is there is already a way to create a QBS profile (using multiplexing)
> that lets you specify the compiler/sdk for host tools and a separate
> combo for the target platform? That's another problem I've chosen to
> ignore thus far, but Christian has suggested that it might be doable
> already.
> 
yes, you specify the profiles property in a product. you'd bind it to
project.hostProfile (which, arguably, should be predefined - cf. the
"self-aware" qbs you mentioned).

> configure is basically a long list of flags, most of them booleans,
> and some attempts to guess what you want.
>
that's mostly the status quo in qt, but it's really way insufficient.
the configuration step should also churn out modules with fully
qualified headers and libraries.

> It seems like a really handy thing for allowing flipping a few bits
> and rebuilding only the parts of Qt which are affected, and something
> that QBS should be really good at. That's what started this exercise
> in the first place; to be able to disable some arbitrary Qt feature
> and (quickly) see what breaks.
> 
yes, but having a text file where you do that after configuring
(adjusting to the environment) is basically a hack. ideally, you'd flip
the bits that interest you via properties you pass to qbs *before* the
project gets configured. passing these properties in a json/qml file
instead of individually would certainly have some appeal. so would some
more specialized command line (like the current configure), and so would
an interactive frontend (like ccmake).

> >not exactly ... that's something that should be created as a side effect
> >of instantiating QtModule, etc. - https://bugreports.qt.io/browse/QBS-268
> 
> Yes, that's exactly the feature I was looking for :-) It would be nice to get
> to the point where "installing Qt" just means running qbs-setup-qt <magic> and
> pointing to your source tree. Then, Qt itself is built bit-by-bit based on
> your projects' dependencies...
> 
that's different. if you want to make qt part of your project, you'd
just refer to qt as a subproject. this does not need any exported module
configs, and will already work out of the box.

> >>qmake isn't even built with this setup, but a stand-in binary called
> >>qhost pacifies the need for querying qmake variables.
> >>
> >well, that's obviously not going to fly for upstreaming, as qmake and
> >everything around it is part of the qt api.
> 
> I'm sure that bothers you more than it bothers me. I mean, requiring qbs
> already means requiring a pre-built host tool.
>
that's besides the point. qmake must stay until qt6 for our users. the
presumption that you don't need qmake if you build qt with qbs falls
flat latest when building with qbs becomes the only option. which will
be very soon after the build system is complete.

> Anyway, thanks for the feedback so far. I guess we could/should start with a
> qbs wip branch in one repo (qtbase, presumably) to get the party started. The
> other repositories can follow when there's a reasonable baseline established.
> 
indeed.
qtbase//wip/qbs-5.5 exists now (which means that there will be at least
curious, probably skeptical, and possibly hostile voices to be heard
soon).