[QBS] Building Qt with QBS

[Oswald Buddenhagen]

On Tue, Mar 31, 2015 at 03:17:59AM +0300, Andrew Knight wrote:
> For the past few months, I've been tinkering with using QBS to build
> the Qt libs we use in our projects.
>
that was risky ... if i actually had the time to do what i wanted,
you'd have duplicated quite some work. anyway, busy me, lucky you. ;)

> The reason I'm posting is to just make it known that we (meaning my 
> colleagues and I) are actively working on this,
>
that's excellent news.
what i'm interested in (possibly even more): how much effort do you guys
want to spend on improving qbs itself? considering
https://bugreports.qt.io/browse/QBS-70's longish list of dependencies
required for a *clean* qbs-based qt build system, quite some work lies
ahead.

> - The repository itself is just a collection of QBS files (and maybe a 
> few JS files as well as some pre-built artifacts I haven't bothered 
> writing rules for yet). That means it is designed to work with a 
> separate checkout (or even tarballs) of Qt sources (e.g. qt5.git). I 
> would also like to see it not tied to any particular Qt version, but to 
> support a range of Qt releases to allow quick switching between Qt 
> sources (read: branching of the repo is not tightly tied to the Qt version).
> 
i understand your motivation for this, but from my perspective it's a
total no-go - it's an utter maintenance nightmare.

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.

> - There are two "prerequisite" steps to building Qt modules:

> (1) build the host tools (using the host's profile)
> Host tools can be reused for every target profile you decide to build
> the framework for.
>
that's something i want to do independently from migrating to qbs.
there are some challenges though, in particular how qmake ties it all
together with its properties.

the inverse conclusion is that this *should* not be a prerequisite for
building with qbs, and i'd prefer to not have it unless we (you ;)
solve the problem upstream before that.

> (2) create a configuration file with all the various switches.
> The configuration file (let's call it qtconfig.json) is basically a
> portable configure command line.
> 
well, that's what i wanted to do for the time being as well.
in fact, i'd have been even cheaper than you: just use the existing
configures and extract the relevant information from the generated .pri
files. the reason for that is the thread you linked to yourself:
whatever you hack up now will probably need a lot of rewriting when
properly modularized configure support is implemented in qbs.
i haven't thought much beyond qtbase, of course. :D

> It would at least be cool, to see this step also install the Qt module
> configurations into a new QBS profile (perhaps as a replacement to
> qbs-setup-qt, see [0]), as that might allow reusing more of QBS's
> existing Qt module support.
> 
not exactly ... that's something that should be created as a side effect
of instantiating QtModule, etc. - https://bugreports.qt.io/browse/QBS-268

> 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.
but rectifying that as such is trivial. the challenges start with the
decoupling of host and target qmake, as noted above.

regards